Questions and Answers

Dual-Use Keywords Create Confusion

Pete Becker is Senior QA Project Manager for C++ at Borland International. He has been involved with C++ as a developer and manager at Borland for the past six years, and is Borland's principal representative to the ANSI/ISO C++ standardization committee.

To ask Pete a question about C or C++, send e-mail to [email protected], use subject line: Questions and Answers, or write to Pete Becker, C/C++ Users Journal, 1601 W. 23rd St., Ste. 200, Lawrence, KS 66046.

Q

I have some questions about overriding operator new. If I override the global new, how can I call the original default new? i.e.:

void* operator new(size_t s)
   {
   return ::new X;
   }

void* operator new(size_t s)
   {
   return ::new unsigned char[s];
   }
void operator delete(void* p)
   {
   if (p) ::delete[] p;
   }

Most people get confused when they first try to modify the behavior of the memory management primitives in C++. One of the biggest contributors to this confusion is that C++ uses each of the keywords new and delete in two different ways. If you're having trouble understanding what this question is asking, blame it on these dual meanings.

The most common use of new occurs in what is known in the language definition as a new-expression: an expression that tells the compiler to allocate memory. For example,

Complex *c = new Complex;

The new-expression can also supply arguments to the constructor for the object being created:

Complex *c = new Complex( 0.0, 1.0 );

Finally, the new-expression can allocate an array of objects, like this:

Complex *c = new Complex[20];

When you are finished with any objects that were created by a new-expression you must delete them. Deleting an object tells the compiler to call the destructor for the object and then to release the memory that the object occupied. There are two forms of delete, one for single objects (regardless of whether they were created with the default constructor or with a constructor that takes parameters) and one for arrays of objects. Don't confuse these two: you must use the array form of delete for pointers to objects that were allocated with the array form of new, and you must not use the array form of delete for pointers to objects that were not allocated with the array form of new. Some compilers let you get away with using the non-array form of delete when you use the array form of new to create objects that do not have destructors, such as the built-in types. Don't depend on this, however; always use the correct form.

The two forms of delete look like this:

Complex *ptr = new Complex;
delete ptr;       // non-array version
Complex *array = new Complex[20];
delete [] array; // array version

void *operator new( size_t sz )
{
   void *p = malloc( sz );
   if( p == 0 )
      throw bad_alloc( );
   return p;
}

void operator delete( void *ptr )
{
   free( ptr );
}

Now, since there are special forms of new and delete for handling arrays, it seems logical that there would be special forms of operator new and operator delete for managing memory associated with arrays of objects. There are. They are generally referred to as array new and array delete, and they are written like this:

void *operator new []( size_t sz )
{
   void *p = malloc( sz );
   if( p == 0 )
      throw bad_alloc( );
   return p;
}

void operator delete [] ( void *ptr )
{
   free( ptr );
}

The suggestion of implementing operator new in terms of operator new[] is intriguing, but it won't work in most cases. The problem is that it imposes a severe limitation on applications that use it: they cannot provide their own version of array new, since it is already used as the hook for getting back to the implementation's memory manager. On first sight this may not seem like much of a problem, but in practice it turns out to be a major impediment. In fact, C++ originally did not have an array new. operator new would be invoked for creation of single objects, and the implementation's memory manager would be invoked for creation of arrays of objects. As people used C++ more and more, it became clear that if you wanted to provide specialized memory management for objects, you probably wanted it regardless of whether you were creating a single object or an array. The need for specialized memory management led to a change in the language specification, so that we now can supply both operator new and operator new[].

It may appear attractive to use operator new[] to get back to the implementation's memory management system, but this is guaranteed to fail by the draft standard. operator new[] calls operator new, which has already been replaced by user code — another infinite loop. In fact, it is rarely appropriate to globally replace the implementation's memory management. Instead, it's usually better to provide class-specific memory management, so that you have the flexibility to use specialized memory managers as needed, rather than imposing a memory manager on the entire application. To do this, just add operator new and operator delete (and the array versions of each) to any class that requires special handling. Then any time you use new to create an object of your class or any class derived from it the version of operator new defined in your class will be used. From this operator new you can call the global version of operator new.

Q

What is this STL? Is it the standard library for C++? I am considering using C++ for my next project but I feel it is such a pain to implement all the basic ADTs such as hash tables and lists. I would like to know if any Standard C++ library for container classes exists. The reason is I like my code to be as portable as possible.

A

STL is the Standard Template Library, developed by Alex Stepanov and Meng Lee at Hewlett Packard. It has been adopted into the C++ working paper and very likely will become part of the language standard. STL provides a rich set of templates for container classes, so programs that use these templates will be portable to compilers that conform to the language definition. Don't expect full portability for a couple of years yet: STL uses templates in ways that challenge the abilities of every compiler on the market today.

STL is not the standard library — it is only part of it. The standard library contains many deal more things: among them iostreams, locales, strings, numerics, algorithms, and containers. STL provides the algorithms and containers.

STL, however, is a great deal more than the specific algorithms and containers required as part of the standard library. It also specifies how algorithms and containers talk to each other. This protocol specification is what gives STL its true power. If you write a container that satisfies STL's requirements for a container you can use any of the algorithms provided by STL on that container. This means you don't have to write code to find an entry in your container that matches a value specified by a user; STL's find() template will do it. You don't have to write code to find the objects in your container with the smallest or the largest value; STL's main() and max() templates will do it.

If you want more details about STL you can get a copy of the specification that was submitted to the ANSI/ISO committee and a public domain implementation of STL by anonymous ftp from butler.hpl.hp.com.

Q

I've got a base class that calls a virtual member function in the constructor. The problem is that when a derived class calls the base constructor, the base class's virtual function is called instead of the derived class's virtual function. However, in another function in the base class, the same virtual function is called, and in this case it works "correctly" — the derived class's member is called. What gives? Is C++ defined this way, or is it a bug? It seems that the behavior should be consistent, but it is not.

A

C++ is defined that way. Virtual functions are not treated as virtual when they are called from a constructor or a destructor. That's because the derived class hasn't been constructed yet when a virtual function is called in a constructor, and it has already been destroyed when a virtual function is called in a destructor. Consider a slightly contrived example:

class Base
{
public:
   Base() { Crash(); }
   virtual void Crash() {}
};

class Derived : public Base
{
public:
   Derived() : Pointer(new int) {}
   void Crash() { *Pointer = 0; }
private:
   int *Pointer;
};

Derived D;

Keep in mind that in C++ objects have a lifetime. An object is brought to life by running its constructor. When the constructor has finished, the object has all the capabilities that its definition supplies. When the program no longer needs the object it runs the destructor to get rid of the object. After construction and before the destructor has started, the object is complete and usable. While the constructor or the destructor is being run the object is incomplete — calling member functions can be dangerous, and requires detailed knowledge of the current state of construction of the object. The special treatment of virtual functions when they are called from constructors and destructors prevents accidentally calling functions that deal with parts of the object that have not been initialized, and helps limit that danger.

Q

I would like to have the pointer to a class automatically set to zero when it is freed. Is there some way of doing this?

A

Sure. It's easy:

template <class T>
inline void PointerDelete( T*& ptr )
{
delete ptr;
ptr = 0;
}

template <class T>
inline void ArrayDelete( T*& ptr )
{
delete [] ptr;
ptr = 0;
}

int *ip = new int;
PointerDelete( ip );
assert( ip == 0 );

double *dp = new double[20];
ArrayDelete( dp );
assert( dp == 0 );

int *ip = new int;
int *ip1 = ip;
PointerDelete( ip );
assert( ip == 0 );
if( ip1 != 0)
   *ip1 = 3;

The copying here is fairly obvious. There's a more subtle form of copying that can lead to the same problem:

void f( int *ptr )
{
PointerDelete( ptr );
}

int *ip = new int;
f( ip );
if( ip !=0 )
   *ip = 3;

Still, some might argue that setting the pointer to zero and religiously checking for null pointers would probably eliminate many of the problems programmers run into with pointers. So it sounds like this still could be a good idea. I disagree: I think it is ultimately harmful, because it gives programmers a false sense of security. Once programmers start assuming that pointers will be set to zero they won't be as alert to the exceptions, and errors like the one above will become more common and harder to track down. This solution is weak in that it relies on flags to indicate validity rather than relying on program structure. If the validity of a pointer is clear from the program itself there's no need to check flags. For example:

{
int *ip = new int;
delete ip;
}

In cases where the lifetime of an object accessed through a pointer does not coincide with a program block, the best approach is to adopt a clear discipline for ownership of pointers. When you create an object with new, think about the circumstances which will call for that object's destruction. Document them. Write the rest of your code to work properly with that object.

The ANSI/ISO C++ committee has recently added an auto_ptr template to help with this. When you create an object you put a pointer to it into an auto_ptr object. When the auto_ptr object goes out of scope it deletes the object that it points to. If you copy an auto_ptr object or return one from a function, the original auto_ptr object becomes invalid and the new auto_ptr object points to the object that you created. This lets you pass auto_ptrs to functions and return them from functions with a clear rule for ownership: only one auto_ptr object points to your object at any given time. Consistently applying a discipline like this makes pointer usage much safer.

Now, admittedly, most pointer problems arise in cases more complicated than what I have shown here. But the answer to those more complicated cases is to simplify them, not to add a global policy on pointer values that is unenforceable and less than completely effective. Write the code so that the lifetime of the memory pointed at coincides with the lifetime of the pointer itself. If you cannot do that, make the pointer safer. Wrap it inside an auto_ptr, or, if necessary, add a reference counter, so that the data it points to will not be deleted as long as an outstanding reference to it exists. Dangerous things like pointers should be handled automatically. Don't trust yourself to get the details right.

Q

I am confused on how to use const with a typedef. I expected it to be semantically equivalent to not using a typedef in the same statement.

I'm working with the following code:

typedef char CustomerName_t[30];
typedef char *CustomerName_pt;

class Customer
{
public:
   const CustomerName_pt name(void) const
      { return(name_); }
private:
   CustomerName_t name_;
};

A

The compiler is right. While it's true in both C and C++ that using const with a typedef is semantically equivalent to not using the typedef in the same statement, a lot of language structure lurks behind the phrase "semantically equivalent." In particular, semantic equivalence does not imply that you can simply replace the typedef name with its definition, as if it were a macro, and expect it to mean the same thing.

The syntax for declaring types can get confusing. When you add in const and volatile modifiers you must be extra careful that you know what those modifiers are modifying. When you apply either of those modifiers to a typedef name, treat it as if you had explicitly written the modifier in front of the type name in the typedef. So, for example, if you start with this typedef:

typedef char *text;

typedef char *const "const text";

To see how this works in practice, let's look at some simple cases involving pointers.

typedef char *text;

char ch[2]:
char *cp = ch;
const char *ccp = ch;
char *const cpc = ch;
text tp = ch;
const text ctp = ch;

void f()
{
*cp = 'a';    // OK
*ccp = 'a';   // illegal
*cpc:= 'a';   // OK
*tp = 'a';    // OK
*ctp = 'a';   // OK
}

void g()
{
cp++;         // OK
ccp++;        // OK
cpc++;        // illegal
tp++;         // OK
ctp++;        // illegal
}

Using typedefs can simplify many aspects of a program, but you have to be careful about how you use modifiers with them. Think about what the modifier modifes and you won't run into problems.