//---
SimpleString&
 generate_string() {
  SimpleString localstr("I am a local object!");
  //... maybe do some processing here ...
  return localstr;  //As soon as this function
                    //returns, "localstr" is
                    //destroyed.
}
//---

The local object is destroyed when the function returns. In general, anything inside curly braces is a scope; if you define a local object (i.e. non-static) inside of a scope (as shown in the example), it no longer exists after the closing curly brace of that scope.

Result: dangling reference.

//---
const SimpleString&
 examine_string(const SimpleString& input) {
//... maybe do some processing here ...
  return input;  //If "input" refers to a temporary 
                 //object, that object will be 
                 //destroyed as soon as this
                 //function returns.
}
//---

The C++ compiler is allowed to create an unnamed temporary object for any const reference parameter. After all, you promise not to change the parameter when you declare it const. Unfortunately, the unnamed temporary goes out of scope as soon as control leaves the function, so if you return a const reference parameter by const reference, a dangling reference can result.

Result: dangling reference.

//---
//This function slices objects.
void the_slicer(Base arg) {
  arg.example();
}
//---

//---
Base base;
Derived derived;

cout << "Calling 'the_slicer' on a Base" << endl;
the_slicer(base);     //O.K.

cout << endl;

cout << "Calling 'the_slicer' on a Derived" << endl;
the_slicer(derived);  // Slices "derived";
                      // this is rarely what
                      // you want.
//---

See the Base class | See the Derived class | See the output

When a function parameter is an object, rather than a pointer or a reference to one, then the argument (supplied during a call to the function) for that parameter is passed by value. The compiler will make a copy of the argument (the copy constructor will be invoked) in order to generate the function call. If the argument's type is a derived class of the parameter, then the famous object slicing problem occurs. Any derived class functionality — including overridden virtual methods — is simply thrown away. The function gets what it asked for: its own object of the exact class that was specified in the declaration.

While all of this makes perfect sense to the compiler, it is often counterintuitive to the programmer. When you pass an object of the derived class, you expect the overridden virtual methods to be called. After all, this is what virtual methods are for. Unfortunately, it won't work like that if a derived object is passed by value.

Result: derived parts are "sliced off." Depending on your design, there may be no memory-related issues, but the slicing problem is important enough to be mentioned here.

//---
SimpleString& 
  xform_string_copy(const SimpleString& input) {

  SimpleString *xformed_p = 
    new SimpleString("I will probably be leaked!");
  
  //... maybe do some processing here ...

  return *xformed_p;  //Callers are highly unlikely 
                      //to ever free this object.
}
//---

Your callers are highly unlikely to take an address of the reference and deallocate the object, especially if the return value is used inside of an expression instead of being immediately saved into a variable.

Result: memory leak.

//---
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);
//---

See the Base class | See the Derived class | See the output

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).

//---
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();
//---

See the Base class | See the NotDerived class | See the output

Casts have been likened to the infamous goto [Cli95]. 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.

//---
//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;
//---

See the output

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.

//---
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;
//---

See the output

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.

//---
//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;
//---

Here is a list of common, matched allocation and deallocation methods.

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.