Back to Stringbad: Where the Copy Constructor Goes Wrong
You are now in a position to understand the twofold weirdness of Listing 12.3. (Let’s assume that the output is the one shown after the listing.) The first weirdness is that the program output indicates two more objects destroyed than constructed. The explanation is that the program does create two additional objects, using the default copy constructor. The copy constructor is used to initialize the formal parameter of callme2() when that function is called, and it is used to initialize the object sailor to sports. The default copy constructor doesn’t vocalize its activities, so it doesn’t announce its creations, and it doesn’t increment the num_strings counter. However, the destructor does update the count, and it’s invoked upon the demise of all objects, regardless of how they were constructed. This weirdness is a problem because it means the program doesn’t keep an accurate object count. The solution is to provide an explicit copy constructor that does update the count:
StringBad::StringBad(const String & s)
{
num_strings++;
...// important stuff to go here
}
If your class has a static data member whose value changes when new objects are created, you should provide an explicit copy constructor that handles the accounting.
The second weirdness is the more subtle and dangerous. One symptom is the garbled string contents:
headline2: Dû°
The cause is that the implicit copy constructor copies by value. Consider Listing 12.3, for example. The effect, recall, is this:
sailor.str = sport.str;
This does not copy the string; it copies the pointer to a string. That is, after sailor is initialized to sports, you wind up with two pointers to the same string. That’s not a problem when the operator<<() function uses the pointer to display the string. It is a problem when the destructor is called. Recall that the StringBad destructor frees the memory pointed to by the str pointer. The effect of destroying sailor is this:
delete [] sailor.str; // delete the string that ditto.str points to
The sailor.str pointer points to "Spinach Leaves Bowl for Dollars" because it is assigned the value of sports.str, which points to that string. So the delete statement frees the memory occupied by the string "Spinach Leaves Bowl for Dollars".
Next, the effect of destroying sports is this:
delete [] sports.str; // effect is undefined
Here, sports.str points to the same memory location that has already been freed by the destructor for sailor, and this results in undefined, possibly harmful, behavior. In the case of Listing 12.3, the program produces mangled strings, which is usually a sign of memory mismanagement.
Another disturbing symptom is that attempting to delete the same memory twice can cause the program to abort. Microsoft Visual C++ 2010 (debug mode), for example, displays an error message window saying “Debug Assertion Failed!”, and g++ 4.4.1 on Linux reports “double free or corruption” and aborts. Other systems might provide different messages or even no message, but the same evil lurks within the programs.
Fixing the Problem by Defining an Explicit Copy Constructor
The cure for the problems in the class design is to make a deep copy. That is, rather than just copy the address of the string, the copy constructor should duplicate the string and assign the address of the duplicate to the str member. That way, each object gets its own string rather than referring to another object’s string. And each call of the destructor frees a different string rather than making duplicate attempts at freeing the same string. Here’s how you can code the String copy constructor:
StringBad::StringBad(const StringBad & st)
{
num_strings++; // handle static member update
len = st.len; // same length
str = new char [len + 1]; // allot space
std::strcpy(str, st.str); // copy string to new location
cout << num_strings << ": "" << str
<< "" object created
"; // For Your Information
}
What makes defining the copy constructor necessary is the fact that some class members are new-initialized pointers to data rather than the data themselves. Figure 12.3 illustrates deep copying.
Figure 12.3. An inside look at deep copying.
If a class contains members that are pointers initialized by new, you should define a copy constructor that copies the pointed-to data instead of copying the pointers themselves. This is termed deep copying. The alternative form of copying (memberwise, or shallow, copying) just copies pointer values. A shallow copy is just that—the shallow “scraping off” of pointer information for copying, rather than the deeper “mining” required to copy the constructs referred to by the pointers.