Example 1. simplestring.h

//*** SIMPLESTRING DECLARATION *** 

#ifndef EXAMPLE_SIMPLE_STRING
#define EXAMPLE_SIMPLE_STRING

class SimpleString {
  
public:

  explicit SimpleString(char* data = "");  //Use 'explicit' keyword to disable
                                           //automatic type conversions --
                                           //generally a good idea.

  //Copy constructor and assignment operator.
  SimpleString(const SimpleString& original);  
  SimpleString& operator=(const SimpleString& right_hand_side);

  virtual ~SimpleString();   //Virtual destructor, in case someone inherits
                             //from this class.

  virtual const char* to_cstr() const;  //Get a read-only C string.

  //Many other methods are needed to create a complete string class.
  //This example implements only a tiny subset of these, in order
  //to keep the discussion focused.

  //N.B. no 'inline' methods -- add inlining later, if needed for
  //optimization.

private:
  char* data_p_;   //Distinguish private class members: a trailing underscore
                   //in the name is one common method.
  
};

#endif

//*** END: SIMPLESTRING DECLARATION ***

//*** SIMPLESTRING IMPLEMENTATION *** 

#include <cstring>

#include "simplestring.h"

using namespace std;

//Constructor 
SimpleString::SimpleString(char* data_p) :
  data_p_(new char[strlen(data_p)+1]) {
  strcpy(data_p_,data_p);
}

//Copy constructor.
SimpleString::SimpleString(const SimpleString& original) :
  data_p_(new char[strlen(original.data_p_)+1]) {
  strcpy(data_p_,original.data_p_);
}

//Assignment operator.
SimpleString& 
SimpleString::operator=(const SimpleString& right_hand_side) {
  
  //It is possible for the caller to request assignment to self 
  //(i.e. "a = a;").  Do nothing in this case, or a serious
  //error will result.
  if (this != &right_hand_side) {

    //Allocate a new buffer first.  If this fails (i.e. throws
    //an exception), everything is still consistent. 
    char* data_p = new char[strlen(right_hand_side.data_p_)+1];

    //Now, delete the old buffer, and start using the new one.
    delete [] data_p_;  //(1)
    data_p_ = data_p;   //(2)
    
    //Copy the data over from the right hand side.  We checked
    //before that this is not self assignment, so we are safe.
    //Otherwise, we would have already destroyed this data
    //in statements (1) and (2)!
    strcpy(data_p_,right_hand_side.data_p_);
  }

  //This allows assignments to be chained (i.e. "a = b = c = d;").
  return *this;
}

//Destructor
SimpleString::~SimpleString() {
  //N.B. Use of 'delete []' corresponds to previous use of 'new []'.
  //     Using just 'delete' here would be a disaster.
  delete [] data_p_;
}

//Returns a read-only C string representation.
const char* SimpleString::to_cstr() const {
  return data_p_;
}

//*** END: SIMPLESTRING IMPLEMENTATION ***

//---
//Pattern your classes on this class, at least
//during initial development.  It is safer than
//the defaults that the C++ compiler generates.
class TWC {

public:
  //The default constructor, just so that the examples
  //work.  You'll define your own constructors, which
  //may or may not include the default constructor.
  TWC();  
  
  //You may want to include a virtual destructor,
  //but if derived classes will will define
  //actual copy constructors and assignment
  //operators, there is no way to copy the base
  //class, so be careful.

private:
  //The copy constructor and assignment operator 
  //are disabled.  Clients of this class that attempt 
  //to use them will cause errors at compile time.
  TWC(const TWC&);
  TWC operator=(const TWC&);

};

//The do-nothing default constructor.
TWC::TWC() {}
//---

The key feature of the Training Wheels class is that the copy constructor and assignment operator are declared private. Thus, when someone tries to copy an object of your class or assign one object of your class to another, the compiler generates an error message. The copy constructor and assignment operator being private are not accessible. For example, here is what happens when a program tries to assign one instance of the Training Wheels class to another (the exact wording of the error messages is compiler dependent).

$ g++3 twct.cpp
twc.ex: In function `int main()':
twc.ex:24: `TWC TWC::operator=(const TWC&)' is private
twct.cpp:11: within this context

Related Reading C++ In a Nutshell A Desktop Quick Reference By Ray Lischner

Forgetting to define the copy constructor and the assignment operator is a common error. The Training Wheels class does not prevent you from making it. Users of your class are unlikely to be happy when their code does not compile due to your mistakes. A compiler error, however, is a far more preferable outcome than the disaster of a dangling reference. The Training Wheels class is not a recipe (even in a very local, limited sense) for error-free software; that would be impossible. Instead, the class is an honest recognition of the possibility of errors together with a conscious, calculated attempt to contain the damage. To use the Training Wheels class as the starting point for your own classes constitutes a concrete, practical act of software engineering.

The true engineer knows that the real world is full of uncertainty and error, that her calculations no matter how meticulously done can never capture this world in all of its complexity. The true engineer asks, for example, "what would happen if my estimate of the maximum wind loading on this building is off by a fifty percent, or by a factor of two, or a factor of five?". She accepts the reality of an uncertain world, indeed of her own human fallibility in that world, and it is only through this acceptance that she may achieve a good design. Of course, it is always possible to go too far with such reasoning; the result is commonly referred to as "over-built" or "over-engineered". Nevertheless, this kind of thinking is central to a practical design. We refer to it as adding a safety margin.

In considering the Training Wheels class, we acknowledge the fact that software engineers, too, live in a world of uncertainty and error. The very human act of creating software makes it so. Thus, the true software engineer asks, for example, "what would happen if someone tried to copy an object of my class, or to assign to an object of my class," accepting all the while that mistakes are possible. Using the Training Wheels class instead of the C++ default is an engineer's way of dealing with the very real possibility of these mistakes. It is an example of a safety margin in software.

//---
Base* obj_p = 0;
try {
  obj_p = new Derived;

  throws_exception();

}
//Must catch everything, so that "obj_p"
//does not leak.
catch(...) {
  delete obj_p; //Cleanup.
  throw;        //Rethrow.
}
//---

//---
//Can assign a derived object to a base 
//pointer just like with ordinary pointers.
auto_ptr<Base> obj_sp (new Derived);

//The auto_ptr "obj_sp" will free the 
//object that it points to (if any).
throws_exception();
//---

It is clear that the second example is much less prone to errors. The output is the same in both cases (assuming something eventually catches the exception without rethrowing it).

Deleting Derived Data, Deleting Base Data

The auto_ptr behaves like an ordinary pointer in many respects. When an auto_ptr goes out of scope, however, it automatically deletes the memory that it is holding — something that the ordinary pointer does not do.

In addition to memory leaks, the auto_ptr also prevents dangling references. When you assign one auto_ptr to another, the auto_ptr on the right hand side actually becomes the equivalent of a NULL pointer! The target of the assignment (on the left hand side) now points to the memory that the right hand side auto_ptr pointed to before. This is a powerful example of how the semantics of an operation (in this case assignment) can be defined in C++.

Because C++ is largely compatible with C, it is much easier to port C code into a C++ environment. It does not mean, however, that you should program in C++ as you would in C. In fact, the C++ standard library provides safe, simple solutions to many problems that are very troublesome in C.

For example, arrays and strings are two problematic issues that the C++ standard library solves very well. Here are two programs to illustrate this point. The first is written in the traditional C style, while the other one uses the new features of the C++ standard library.

//*** C STYLE ARRAY OF STRINGS *** 

#include <stdio.h>

void print_strings(char** strings, unsigned num) {
  
  for (int i = 0; i < num; ++i) {
    printf("%s\n",strings[i]);
  }
}

int main() {

  char* strings[3] = {"One", "Two", "Three"};

  print_strings(strings, 3);
}

//*** END: C STYLE ARRAY OF STRINGS ***

//*** C++ STYLE ARRAY OF STRINGS *** 

#include <iostream>
#include <string>
#include <vector>
using namespace std;

void print_strings(const vector<string>& strings) {
  
  for (int i=0; i < strings.size(); ++i) {
    cout << strings[i] << endl;
  } 
}

int main() {

  vector<string> strings(3);
  strings[0] = "One"; strings[1] = "Two"; strings[2] = "Three";
  
  print_strings(strings);
}

//*** END: C++ STYLE ARRAY OF STRINGS ***

Both examples produce the same output.

One
Two
Three

//*** C++ STYLE ARRAY OF STRINGS (VERSION 2) *** 

#include <iostream>
#include <string>
#include <vector>
using namespace std;

void print_strings(const vector<string>& strings) {
  
  for (int i=0; i < strings.size(); ++i) {
    cout << strings[i] << endl;
  } 
}

int main() {
  vector<string> strings(3);
  strings[0] = "One"; strings[1] = "Two"; strings[2] = "Three";
  
  print_strings(strings);

  strings[0] += " and a";
  strings[1] += " and a";

  strings.resize(4);
  strings[3] = "and One, Two, Three!";

  cout << endl << "Encore!" << endl << endl;
  print_strings(strings);
}

//*** END: C++ STYLE ARRAY OF STRINGS (VERSION 2) ***

Here is the output.

One
Two
Three

Encore!

One and a
Two and a
Three
and One, Two, Three!

The C++ reference seems at first such an ungainly thing. Why would anyone want an alias for an existing object? Isn't it merely confusing? This skepticism of references is usually due to the way they are presented. The real place where references make a profound difference is in parameters to functions and catch clauses. Under these circumstances, references are overwhelmingly desirable, as shown in the following list.

//---
SimpleString return_by_value() {

  //Constructing the return value like this (as part
  //of the "return" statement) helps the compiler
  //eliminate the temporary objects associated with
  //return-by-value.
  return SimpleString("Return Value Optimization");
}
//---

While avoiding return-by-value is a worthwhile goal, be prepared for the fact that it may not be possible. In those situations, give the compiler a hint as shown in the example, and accept whatever performance hit remains. It is indeed a poor bargain to allow a memory leak or a dangling reference in order to get a boost in performance.

The goto. The pointer cast. Memory allocation? Unfortunately, not all harmful things in this world can be avoided. Memory allocation is one of them. After reading this series of articles, you probably would not be surprised to learn that the majority of both C++ and C errors are related to memory. Yes, memory allocation truly is harmful.

The prescription for allocating memory is actually similar to the one for goto. You can, in fact, avoid memory allocation in the majority of your code by encapsulating memory management in its own subsystem. Operations with memory are like toxic chemicals: extremely useful if confined to a small area and put to work, but terribly destructive if allowed to leak out. This series of articles presented several techniques, such as smart pointers and allocators, that can restrict memory operations to a well-defined part of the code. Keep your memory operations bottled up, where you can use them to your benefit in relative safety, and wonderful things should happen to your program.

Memory allocation: it's harmful but good!

If you remember only one thing from this article series, it is that every C++ program needs a memory management design. After all, the designers of memory-managed languages such as Java and Python have put a great deal of thought into their automated memory management schemes. In C++, this task is up to you.

If you will be developing a subsystem for a specific application rather than a general-purpose language, your approach to memory management can be much simpler and much more focused. Nevertheless, you will need an approach. Ad-hoc calls to new all over your program will just leave you chasing memory leaks and dangling references, which is a thankless task that quickly becomes impossible as the program grows. A sound memory management design, on the other hand, will allow you to fine-tune your code safely, in ways not possible with a memory-managed language. This is the key to effective use of C++.

[Cli95] Marshall P Cline and Greg A Lomow. C++ FAQs. Frequently Asked Questions. Addison-Wesley Publishing Co., Inc.. Copyright 1995. 0-201-58958-3.

[Fey88] Richard Feynman and Ralph Leighton. "What Do You Care What Other People Think?". Further Adventures of a Curious Character. W.W. Norton & Company, Inc.. Copyright 1998 Gweneth Feynman and Ralph Leighton. 0-393-02659-0.

[Mey96] Scott Meyers. More Effective C++. 35 New Ways to Improve Your Programs and Designs. Addison-Wesley Longman, Inc.. Copyright 1996. 020163371X.

[Mey98] Scott Meyers. Effective C++. 50 Specific Ways to Improve Your Programs and Designs. Second. Addison-Wesley. Copyright 1998. 0-201-92488-9.

[Poh02] Ira Pohl. C++ by Dissection. The Essentials of C++ Programming. Addison-Wesley. Copyright 2002. 0-201-74396-5.