Intermediate C++ Game Programming Tutorial 6

From Chilipedia
Jump to: navigation, search

This tutorial is epoch-making; DO NOT SKIP IT. The ostensive main topic for this video is destructors, but that is not where its soul lies. After learning about dtors, we are ready to discuss a matter that is at the heart of C++: RAII. This will form the bridge between low-level memory management, and high level smart objects. We also discuss the important concept of deep copying and the Rule of 3, and related to this, we review the 4 original special member functions. AND there are discussion of a bunch of other random bullshit, like converting construction for example. It's a big video is what I'm tryin' to say here.

Topics Covered

  • RAII (Resource Allocation Is Initialization)
  • Deep Copy vs. Shallow Copy
  • Rule of 3 / Rule of 0
  • Destructors
  • Special Member Functions
  • Converting Constructors
  • explicit Keyword for Constructors
  • Copy Construction with Assignment operator =
  • Constructing with () vs. with {}
  • Deleting Special Member Functions with = delete
  • Conditions when Special Members Cannot be Generated by Compiler


Video Timestamp Index

Source Code

GitHub Repo for Memesweeper
GitHub Repo for Tutorial 6
GitHub Repo for Homework (Stack)

Homework

The homework is to create a stack container that is implemented with with a linked list data structure. The skeleton of the interface for the Stack class is given in the source code (see the Downloads above). These are the minimum functions that must be implemented. For further information on stacks, see this video. For further information on linked lists, see this video. Furthermore, additional research is highly recommended.

The behaviors of the interface functions are for the student to infer, with the exception of the Pop() function. In the case of calling Pop() on an empty stack, the function shall return -1. The internal implementation details are also to be determined by the student, but they must at their core use a linked list data structure.

When the Stack is fully implemented and the program is executed, there are 8 test routines that will be run. All test routines should output 'Passed' to the console for the homework to be considered solved. Furthermore, the heap memory will be monitored at the end of the program and any dynamic memory that has not been freed will trigger a diagnostic error message. It is required that no diagnostic error be output for the homework to be considered solved.

The string routines developed during Intermediate are available for use (but are not strictly necessary). The student may not modify any of the test code. The student may not use any additional classes/functions from the standard library or any 3rd party library. If necessary, it is recommended that the Stack class be developed in a separate solution and tested with custom testing code and diagnostic outputs. Then when the Stack class is deemed ready, it can be transplanted into the test solution for final validation.

Errata

  • It is very important to check for self assignment. If the user of your class tries to do myObj = myObj;, and you do not detect this case, what your code will do is allocate new memory, set myObj's internal pointer to that memory (leaking it), and then it will delete the new memory, giving you an invalid pointer. Actual cancer. Chili neglected to do a check for this case in his examples or in the homework solution, and for this he is surely going to Hell.
  • The destructor of DynamicIntArray frees the dynamic memory block with delete pArray, but since it was allocated with new int[] it should have been freed with delete [] pArray.
  • The text at 39:38 got messed up and goes off of the screen partially. It should have read: "Remember, before assignment the object being assigned to already owned some memory, and when we overwrite the pointer we lose track of that memory forever."
  • In Stack::Element, we implement the destructor and the copy constructor, but not the copy assignment. This violates the Rule of 3, and if someone later accidentally uses the copy assignment operator (fairly possible), they're gonna get their shit fucked up. Since we don't need it, it would be best just to delete it with = delete.

See also