Errors when Defining Methods in Classes
C++ Default Methods
You must make sure that the default methods that C++ generates work well with your design. The default copy constructor and assignment operator tend to cause the most trouble to programmers. This was extensively covered previously.
Result: memory leak and/or dangling reference.
The Non-Virtual Destructor
If you intend others to inherit from your class, you must declare its destructor virtual. Otherwise, the derived class’ destructor may not be called in circumstances such as the one shown in the example.
Result: memory leak; possibly other problems.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | //--- //NVDBase has a non-virtual destructor. NVDBase* base_p = new NVDBase; NVDDerived *derived_p = new NVDDerived; //A base-type pointer to a derived object: //an essential feature in C++. NVDBase* btd_p = new NVDDerived; delete base_p; //O.K. delete derived_p; //O.K. delete btd_p; //Error! Will call only NVDBase's //destructor, even though "btd_p" //points at an NVDDerived! The //object will not be properly //destructed. //--- |
Errors in Handling of Allocated Memory or Objects
Using Arrays Polymorphically
The ability to access a derived object through a reference or pointer of the base type is central to C++. It allows an important kind of polymorphism (literally, an ability to assume different forms) in which virtual method calls are made based on the actual (fully derived) type of the object, even though the pointer or reference is of the base type.
Unfortunately, this sort of polymorphism does not work with arrays of classes. C++ inherits its arrays from C ? there is basically no difference between an array and a pointer. As you index into an array of derived objects via a base-type pointer, the compiler is happily doing the pointer arithmetic using the size of the base class. The derived class, however, is almost certainly larger than the base class, due to extra members that have been added. Thus, the returned data is rarely a single valid object, but rather pieces of two adjacent ones.
Result: wild pointer (recall that dangling references are a special case of wild pointer).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | //--- void process_array(Base* array, unsigned len) { for (int i = 0; i < len; ++i) { array[i].example(); } } //--- //--- Base array_of_base[3]; Derived array_of_derived[3]; //This works as expected. process_array(array_of_base,3); cout << endl; //This is a disaster! process_array(array_of_derived,3); //--- |
Mistakes Using Casts
Casts have been likened to the infamous goto. This is not completely fair, but nevertheless, casts are rarely required in a well-designed C++ program. A cast will, for example, allow you to convert between two pointers to completely unrelated classes. This produces a wild pointer (recall that dangling references are a type of wild pointer). If you decide to use a cast, make it a very specific, limited part of your program ? preferably hidden away in the internal details of a class. Also, try to use the C++ style casts in preference to the older C style casts. The former come in several varieties, each capable only of a particular kind of conversion, generally making them far safer than the indiscriminate C casts.
Result: wild pointer.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 | //--- Base base; Base *base_p = &base; //Here, the programmer mistakenly believes that //NotDerived is derived from Base, and that "base_p" //points to a NotDerived object (which would be //perfectly legal if, in fact, NotDerived *was* //derived from Base). //Old C cast is indiscriminate. NotDerived* wild_p = (NotDerived*)base_p; cout << "Value of 'wild_p' is now: " << wild_p << endl; //This will not be soothing at all! wild_p->soothe_me(); cout << endl; //The C++ dynamic_cast is specifically for //"casting down" the class hierarchy. wild_p = dynamic_cast<NotDerived*>(base_p); //The pointer "base_p" does *not* point at a //NotDerived object; dynamic_cast returns a //NULL pointer. cout << "Value of 'wild_p' is now: " << wild_p << endl; //At least the program will just crash immediately, //instead of doing something crazy. A NULL pointer //is much better than a wild pointer! wild_p->soothe_me(); //--- |
Bitwise Copying of Objects
Mechanisms such as the memcpy function simply copy memory bit by bit. Not all objects, however, can be copied this way without damage. A C++ object is not a piece of dead data; it is a living, intelligent collection of data and functions. When an object is copied, for example, its copy constructor might need to allocate memory, notify other objects, etc. A bitwise copy circumvents these kinds of operations. This results in a seriously broken copy, in many cases.
Besides memcpy, other bit-by-bit copies can result from realloc (it makes such copies when it reallocates memory). An especially easy mistake to make is with variable argument lists. Passing a C++ object using a variable argument list results in a bitwise copy, and is therefore very dangerous (although passing pointers to objects will work, as long as you are mindful of the fact that va_arg uses casts).
Result: memory leaks and dangling references are both possible, as well as other problems.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | //--- //Get multiple strings via a variable argument //list, and print them out. void print_strings(unsigned num ...) { va_list narg_p; va_start (narg_p, num); for (unsigned i = 0; i < num; ++i) { SimpleString str = va_arg(narg_p, SimpleString); cout << str.to_cstr() << " "; } cout << endl; } //--- //--- SimpleString first("one"); SimpleString second("two"); //Print out the SimpleStrins directly, //just to show that everything is O.K. cout << first.to_cstr() << " " << second.to_cstr() << endl; //Causes bitwise copies of the //objects -- serious error. print_strings(2,first,second); //We may or may not get here -- //it all depends on luck! cout << first.to_cstr() << " " << second.to_cstr() << endl; //--- |
Deallocation of Memory That Was Not Dynamically Allocated
It is important to make sure that any memory you free has, in fact, been dynamically allocated. Actions such as freeing local objects or deallocating memory more than once will be disastrous to your program. This also applies to using delete this; inside of a method of your class ? you must indeed be sure that the object has been dynamically allocated before you try to delete it.
Result: memory leaks and dangling references, as well as corruption of operating system data structures.
1 2 3 4 5 6 7 8 9 10 11 12 | //--- SimpleString str("I am a local object!"); SimpleString* str_p = &str; //O.K. to use, like any other pointer. cout << str_p->to_cstr() << endl; //The object pointed to by "str_p" was not //dynamically allocated; you should *never* //do the following. delete str_p; //--- |
Mismatched Method of Allocation and Deallocation
Here is a list of common, matched allocation and deallocation methods.
| new | delete |
| new [] | delete [] |
| malloc() | free() |
It is a serious error to allocate with one method, and then use something other than the corresponding deallocation method to release the memory. In addition, note that malloc and free are not recommended in C++ ? they are not typesafe, and do not call constructors and destructors.
You should also never call an object’s destructor directly. The only exception to this is when you allocate the object using the placement new syntax (e.g. new (ptr_to_allocated_mem) MyClass;). In that case, you should call the object’s destructor when you are finished using it, especially before freeing the memory pointed to by pointer_to_allocated_mem (how you free the memory depends on how you allocated it in the first place).
Result: memory leaks and corruption of operating system data structures.
1 2 3 4 5 6 7 8 | //--- //Allocate via "new []" -- the array new. SimpleString* str_pa = new SimpleString[10]; //A common but serious error -- you must use the //array delete (i.e. "delete [] str_pa;") here. delete str_pa; //--- |
By George Belotsky Initially published on Linux DevCenter (http://www.linuxdevcenter.com/)
