[16] Freestore management
(Part of C++ FAQ Lite, Copyright © 1991-2006, Marshall Cline, cline@parashift.com)

FAQs in section [16]:

• [16.1] Does delete p delete the pointer p, or the pointed-to-data *p?
• [16.2] Is it safe to delete the same pointer twice?
• [16.3] Can I free() pointers allocated with new? Can I delete pointers allocated with malloc()?
• [16.4] Why should I use new instead of trustworthy old malloc()?
• [16.5] Can I use realloc() on pointers allocated via new?
• [16.6] Do I need to check for NULL after p = new Fred()?
• [16.7] How can I convince my (older) compiler to automatically check new to see if it returns NULL?
• [16.8] Do I need to check for NULL before delete p?
• [16.9] What are the two steps that happen when I say delete p?
• [16.10] In p = new Fred(), does the Fred memory "leak" if the Fred constructor throws an exception?
• [16.11] How do I allocate / unallocate an array of things?
• [16.12] What if I forget the [] when deleteing array allocated via new T[n]?
• [16.13] Can I drop the [] when deleteing array of some built-in type (char, int, etc)?
• [16.14] After p = new Fred[n], how does the compiler know there are n objects to be destructed during delete[] p?
• [16.15] Is it legal (and moral) for a member function to say delete this?
• [16.16] How do I allocate multidimensional arrays using new?
• [16.17] But the previous FAQ's code is SOOOO tricky and error prone! Isn't there a simpler way?
• [16.18] But the above Matrix class is specific to Fred! Isn't there a way to make it generic?
• [16.19] What's another way to build a Matrix template?
• [16.20] Does C++ have arrays whose length can be specified at run-time?
• [16.21] How can I force objects of my class to always be created via new rather than as locals or global/static objects?
• [16.22] How do I do simple reference counting?
• [16.23] How do I provide reference counting with copy-on-write semantics?
• [16.24] How do I provide reference counting with copy-on-write semantics for a hierarchy of classes?
• [16.25] Can you absolutely prevent people from subverting the reference counting mechanism, and if so, should you?
• [16.26] Can I use a garbage collector in C++?
• [16.27] What are the two kinds of garbage collectors for C++?
• [16.28] Where can I get more info on garbage collectors for C++?

The pointed-to-data.

The keyword should really be delete_the_thing_pointed_to_by. The same abuse of English occurs when freeing the memory pointed to by a pointer in C: free(p) really means free_the_stuff_pointed_to_by(p).

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

No! (Assuming you didn't get that pointer back from new in between.)

For example, the following is a disaster:

That second delete p line might do some really bad things to you. It might, depending on the phase of the moon, corrupt your heap, crash your program, make arbitrary and bizarre changes to objects that are already out there on the heap, etc. Unfortunately these symptoms can appear and disappear randomly. According to Murphy's law, you'll be hit the hardest at the worst possible moment (when the customer is looking, when a high-value transaction is trying to post, etc.).

Note: some runtime systems will protect you from certain very simple cases of double delete. Depending on the details, you might be okay if you happen to be running on one of those systems and if no one ever deploys your code on another system that handles things differently and if you are deleting something that doesn't have a destructor and if you don't do anything significant between the two deletes and if no one ever changes your code to do something significant between the two deletes and if your thread scheduler (over which you likely have no control!) doesn't happen to swap threads between the two deletes and if, and if, and if. So back to Murphy: since it can go wrong, it will, and it will go wrong at the worst possible moment.

Do NOT email me saying you tested it and it doesn't crash. Get a clue. A non-crash don't prove the absence of a bug; it merely fails to prove the presence of a bug.

Trust me: double-delete is bad, bad, bad. Just say no.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

No!

It is perfectly legal, moral, and wholesome to use malloc() and delete in the same program, or to use new and free() in the same program. But it is illegal, immoral, and despicable to call free() with a pointer allocated via new, or to call delete on a pointer allocated via malloc().

Beware! I occasionally get e-mail from people telling me that it works OK for them on machine X and compiler Y. Just because they don't see bad symptoms in a simple test case doesn't mean it won't crash in the field. Even if they know it won't crash on their particular compiler doesn't mean it will work safely on another compiler, another platform, or even another version of the same compiler.

Beware! Sometimes people say, "But I'm just working with an array of char." Nonetheless do not mix malloc() and delete on the same pointer, or new and free() on the same pointer! If you allocated via p = new char[n], you must use delete[] p; you must not use free(p). Or if you allocated via p = malloc(n), you must use free(p); you must not use delete[] p or delete p! Mixing these up could cause a catastrophic failure at runtime if the code was ported to a new machine, a new compiler, or even a new version of the same compiler.

You have been warned.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Constructors/destructors, type safety, overridability.

• Constructors/destructors: unlike malloc(sizeof(Fred)), new Fred() calls Fred's constructor. Similarly, delete p calls *p's destructor.
• Type safety: malloc() returns a void* which isn't type safe. new Fred() returns a pointer of the right type (a Fred*).
• Overridability: new is an operator that can be overridden by a class, while malloc() is not overridable on a per-class basis.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

No!

When realloc() has to copy the allocation, it uses a bitwise copy operation, which will tear many C++ objects to shreds. C++ objects should be allowed to copy themselves. They use their own copy constructor or assignment operator.

Besides all that, the heap that new uses may not be the same as the heap that malloc() and realloc() use!

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

No! (But if you have an old compiler, you may have to force the new operator to throw an exception if it runs out of memory.)

It turns out to be a real pain to always write explicit NULL tests after every new allocation. Code like the following is very tedious:

If your compiler doesn't support (or if you refuse to use) exceptions, your code might be even more tedious:

Take heart. In C++, if the runtime system cannot allocate sizeof(Fred) bytes of memory during p = new Fred(), a std::bad_alloc exception will be thrown. Unlike malloc(), new never returns NULL!

Therefore you should simply write:

However, if your compiler is old, it may not yet support this. Find out by checking your compiler's documentation under "new". If you have an old compiler, you may have to force the compiler to have this behavior.

Note: If you are using Microsoft Visual C++, to get new to throw an exception when it fails you must #include some standard header in at least one of your .cpp files. For example, you could #include <new> (or <iostream> or <string> or ...).

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Eventually your compiler will.

If you have an old compiler that doesn't automagically perform the NULL test, you can force the runtime system to do the test by installing a "new handler" function. Your "new handler" function can do anything you want, such as throw an exception, delete some objects and return (in which case operator new will retry the allocation), print a message and abort() the program, etc.

Here's a sample "new handler" that prints a message and throws an exception. The handler is installed using std::set_new_handler():

After the std::set_new_handler() line is executed, operator new will call your myNewHandler() if/when it runs out of memory. This means that new will never return NULL:

Note: If your compiler doesn't support exception handling, you can, as a last resort, change the line throw ...; to:

Note: If some global/static object's constructor uses new, it won't use the myNewHandler() function since that constructor will get called before main() begins. Unfortunately there's no convenient way to guarantee that the std::set_new_handler() will be called before the first use of new. For example, even if you put the std::set_new_handler() call in the constructor of a global object, you still don't know if the module ("compilation unit") that contains that global object will be elaborated first or last or somewhere inbetween. Therefore you still don't have any guarantee that your call of std::set_new_handler() will happen before any other global's constructor gets invoked.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

No!

The C++ language guarantees that delete p will do nothing if p is equal to NULL. Since you might get the test backwards, and since most testing methodologies force you to explicitly test every branch point, you should not put in the redundant if test.

Wrong:

Right:

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

delete p is a two-step process: it calls the destructor, then releases the memory. The code generated for delete p is functionally similar to this (assuming p is of type Fred*):

The statement p->~Fred() calls the destructor for the Fred object pointed to by p.

The statement operator delete(p) calls the memory deallocation primitive, void operator delete(void* p). This primitive is similar in spirit to free(void* p). (Note, however, that these two are not interchangeable; e.g., there is no guarantee that the two memory deallocation primitives even use the same heap!)

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

No.

If an exception occurs during the Fred constructor of p = new Fred(), the C++ language guarantees that the memory sizeof(Fred) bytes that were allocated will automagically be released back to the heap.

Here are the details: new Fred() is a two-step process:

1. sizeof(Fred) bytes of memory are allocated using the primitive void* operator new(size_t nbytes). This primitive is similar in spirit to malloc(size_t nbytes). (Note, however, that these two are not interchangeable; e.g., there is no guarantee that the two memory allocation primitives even use the same heap!).
2. It constructs an object in that memory by calling the Fred constructor. The pointer returned from the first step is passed as the this parameter to the constructor. This step is wrapped in a try ... catch block to handle the case when an exception is thrown during this step.

Thus the actual generated code is functionally similar to:

The statement marked "Placement new" calls the Fred constructor. The pointer p becomes the this pointer inside the constructor, Fred::Fred().

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Use p = new T[n] and delete[] p:

Any time you allocate an array of objects via new (usually with the [n] in the new expression), you must use [] in the delete statement. This syntax is necessary because there is no syntactic difference between a pointer to a thing and a pointer to an array of things (something we inherited from C).

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

All life comes to a catastrophic end.

It is the programmer's —not the compiler's— responsibility to get the connection between new T[n] and delete[] p correct. If you get it wrong, neither a compile-time nor a run-time error message will be generated by the compiler. Heap corruption is a likely result. Or worse. Your program will probably die.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

No!

Sometimes programmers think that the [] in the delete[] p only exists so the compiler will call the appropriate destructors for all elements in the array. Because of this reasoning, they assume that an array of some built-in type such as char or int can be deleted without the []. E.g., they assume the following is valid code:

But the above code is wrong, and it can cause a disaster at runtime. In particular, the code that's called for delete p is operator delete(void*), but the code that's called for delete[] p is operator delete[](void*). The default behavior for the latter is to call the former, but users are allowed to replace the latter with a different behavior (in which case they would normally also replace the corresponding new code in operator new[](size_t)). If they replaced the delete[] code so it wasn't compatible with the delete code, and you called the wrong one (i.e., if you said delete p rather than delete[] p), you could end up with a disaster at runtime.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Short answer: Magic.

Long answer: The run-time system stores the number of objects, n, somewhere where it can be retrieved if you only know the pointer, p. There are two popular techniques that do this. Both these techniques are in use by commercial-grade compilers, both have tradeoffs, and neither is perfect. These techniques are:

• Over-allocate the array and put n just to the left of the first Fred object.
• Use an associative array with p as the key and n as the value.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

As long as you're careful, it's OK for an object to commit suicide (delete this).

Here's how I define "careful":

1. You must be absolutely 100% positive sure that this object was allocated via new (not by new[], nor by placement new, nor a local object on the stack, nor a global, nor a member of another object; but by plain ordinary new).
2. You must be absolutely 100% positive sure that your member function will be the last member function invoked on this object.
3. You must be absolutely 100% positive sure that the rest of your member function (after the delete this line) doesn't touch any piece of this object (including calling any other member functions or touching any data members).
4. You must be absolutely 100% positive sure that no one even touches the this pointer itself after the delete this line. In other words, you must not examine it, compare it with another pointer, compare it with NULL, print it, cast it, do anything with it.

Naturally the usual caveats apply in cases where your this pointer is a pointer to a base class when you don't have a virtual destructor.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

There are many ways to do this, depending on how flexible you want the array sizing to be. On one extreme, if you know all the dimensions at compile-time, you can allocate multidimensional arrays statically (as in C):

More commonly, the size of the matrix isn't known until run-time but you know that it will be rectangular. In this case you need to use the heap ("freestore"), but at least you are able to allocate all the elements in one freestore chunk.

Finally at the other extreme, you may not even be guaranteed that the matrix is rectangular. For example, if each row could have a different length, you'll need to allocate each row individually. In the following function, ncols[i] is the number of columns in row number i, where i varies between 0 and nrows-1 inclusive.

Note the funny use of matrix[i-1] in the deletion process. This prevents wrap-around of the unsigned value when i goes one step below zero.

Finally, note that pointers and arrays are evil. It is normally much better to encapsulate your pointers in a class that has a safe and simple interface. The following FAQ shows how to do this.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Yep.

The reason the code in the previous FAQ was so tricky and error prone was that it used pointers, and we know that pointers and arrays are evil. The solution is to encapsulate your pointers in a class that has a safe and simple interface. For example, we can define a Matrix class that handles a rectangular matrix so our user code will be vastly simplified when compared to the the rectangular matrix code from the previous FAQ:

The main thing to notice is the lack of clean-up code. For example, there aren't any delete statements in the above code, yet there will be no memory leaks, assuming only that the Matrix destructor does its job correctly.

Here's the Matrix code that makes the above possible:

Note that the above Matrix class accomplishes two things: it moves some tricky memory management code from the user code (e.g., main()) to the class, and it reduces the overall bulk of program. The latter point is important. For example, assuming Matrix is even mildly reusable, moving complexity from the users [plural] of Matrix into Matrix itself [singular] is equivalent to moving complexity from the many to the few. Anyone who's seen Star Trek 2 knows that the good of the many outweighs the good of the few... or the one.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Yep; just use templates:

Here's how this can be used:

Now it's easy to use Matrix<T> for things other than Fred. For example, the following uses a Matrix of std::string (where std::string is the standard string class):

You can thus get an entire family of classes from a template. For example, Matrix<Fred>, Matrix<std::string>, Matrix< Matrix<std::string> >, etc.

Here's one way that the template can be implemented:

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Use the standard vector template, and make a vector of vector.

The following uses a std::vector<std::vector<T> > (note the space between the two > symbols).

Note how much simpler this is than the previous: there is no explicit new in the constructor, and there is no need for any of The Big Three (destructor, copy constructor or assignment operator). Simply put, your code is a lot less likely to have memory leaks if you use std::vector than if you use explicit new T[n] and delete[] p.

Note also that std::vector doesn't force you to allocate numerous chunks of memory. If you prefer to allocate only one chunk of memory for the entire matrix, as was done in the previous, just change the type of data_ to std::vector<T> and add member variables nrows_ and ncols_. You'll figure out the rest: initialize data_ using data_(nrows * ncols), change operator()() to return data_[row*ncols_ + col];, etc.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Yes, in the sense that the standard library has a std::vector template that provides this behavior.

No, in the sense that built-in array types need to have their length specified at compile time.

Yes, in the sense that even built-in array types can specify the first index bounds at run-time. E.g., comparing with the previous FAQ, if you only need the first array dimension to vary then you can just ask new for an array of arrays, rather than an array of pointers to arrays:

You can't do this if you need anything other than the first dimension of the array to change at run-time.

But please, don't use arrays unless you have to. Arrays are evil. Use some object of some class if you can. Use arrays only when you have to.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Use the Named Constructor Idiom.

As usual with the Named Constructor Idiom, the constructors are all private or protected, and there are one or more public static create() methods (the so-called "named constructors"), one per constructor. In this case the create() methods allocate the objects via new. Since the constructors themselves are not public, there is no other way to create objects of the class.

Now the only way to create Fred objects is via Fred::create():

Make sure your constructors are in the protected section if you expect Fred to have derived classes.

Note also that you can make another class Wilma a friend of Fred if you want to allow a Wilma to have a member object of class Fred, but of course this is a softening of the original goal, namely to force Fred objects to be allocated via new.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

If all you want is the ability to pass around a bunch of pointers to the same object, with the feature that the object will automagically get deleted when the last pointer to it disappears, you can use something like the following "smart pointer" class:

Naturally you can use nested classes to rename FredPtr to Fred::Ptr.

Note that you can soften the "never NULL" rule above with a little more checking in the constructor, copy constructor, assignment operator, and destructor. If you do that, you might as well put a p_ != NULL check into the "*" and "->" operators (at least as an assert()). I would recommend against an operator Fred*() method, since that would let people accidentally get at the Fred*.

One of the implicit constraints on FredPtr is that it must only point to Fred objects which have been allocated via new. If you want to be really safe, you can enforce this constraint by making all of Fred's constructors private, and for each constructor have a public (static) create() method which allocates the Fred object via new and returns a FredPtr (not a Fred*). That way the only way anyone could create a Fred object would be to get a FredPtr ("Fred* p = new Fred()" would be replaced by "FredPtr p = Fred::create()"). Thus no one could accidentally subvert the reference counting mechanism.

For example, if Fred had a Fred::Fred() and a Fred::Fred(int i, int j), the changes to class Fred would be:

The end result is that you now have a way to use simple reference counting to provide "pointer semantics" for a given object. Users of your Fred class explicitly use FredPtr objects, which act more or less like Fred* pointers. The benefit is that users can make as many copies of their FredPtr "smart pointer" objects, and the pointed-to Fred object will automagically get deleted when the last such FredPtr object vanishes.

If you'd rather give your users "reference semantics" rather than "pointer semantics," you can use reference counting to provide "copy on write".

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Reference counting can be done with either pointer semantics or reference semantics. The previous FAQ shows how to do reference counting with pointer semantics. This FAQ shows how to do reference counting with reference semantics.

The basic idea is to allow users to think they're copying your Fred objects, but in reality the underlying implementation doesn't actually do any copying unless and until some user actually tries to modify the underlying Fred object.

Class Fred::Data houses all the data that would normally go into the Fred class. Fred::Data also has an extra data member, count_, to manage the reference counting. Class Fred ends up being a "smart reference" that (internally) points to a Fred::Data.

If it is fairly common to call Fred's default constructor, you can avoid all those new calls by sharing a common Fred::Data object for all Freds that are constructed via Fred::Fred(). To avoid static initialization order problems, this shared Fred::Data object is created "on first use" inside a function. Here are the changes that would be made to the above code (note that the shared Fred::Data object's destructor is never invoked; if that is a problem, either hope you don't have any static initialization order problems, or drop back to the approach described above):

Note: You can also provide reference counting for a hierarchy of classes if your Fred class would normally have been a base class.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

The previous FAQ presented a reference counting scheme that provided users with reference semantics, but did so for a single class rather than for a hierarchy of classes. This FAQ extends the previous technique to allow for a hierarchy of classes. The basic difference is that Fred::Data is now the root of a hierarchy of classes, which probably cause it to have some virtual functions. Note that class Fred itself will still not have any virtual functions.

The Virtual Constructor Idiom is used to make copies of the Fred::Data objects. To select which derived class to create, the sample code below uses the Named Constructor Idiom, but other techniques are possible (a switch statement in the constructor, etc). The sample code assumes two derived classes: Der1 and Der2. Methods in the derived classes are unaware of the reference counting.

Naturally the constructors and sampleXXX methods for Fred::Der1 and Fred::Der2 will need to be implemented in whatever way is appropriate.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

No, and (normally) no.

There are two basic approaches to subverting the reference counting mechanism:

1. The scheme could be subverted if someone got a Fred* (rather than being forced to use a FredPtr). Someone could get a Fred* if class FredPtr has an operator*() that returns a Fred&: FredPtr p = Fred::create(); Fred* p2 = &*p;. Yes it's bizarre and unexpected, but it could happen. This hole could be closed in two ways: overload Fred::operator&() so it returns a FredPtr, or change the return type of FredPtr::operator*() so it returns a FredRef (FredRef would be a class that simulates a reference; it would need to have all the methods that Fred has, and it would need to forward all those method calls to the underlying Fred object; there might be a performance penalty for this second choice depending on how good the compiler is at inlining methods). Another way to fix this is to eliminate FredPtr::operator*() — and lose the corresponding ability to get and use a Fred&. But even if you did all this, someone could still generate a Fred* by explicitly calling operator->(): FredPtr p = Fred::create(); Fred* p2 = p.operator->();.
2. The scheme could be subverted if someone had a leak and/or dangling pointer to a FredPtr Basically what we're saying here is that Fred is now safe, but we somehow want to prevent people from doing stupid things with FredPtr objects. (And if we could solve that via FredPtrPtr objects, we'd have the same problem again with them). One hole here is if someone created a FredPtr using new, then allowed the FredPtr to leak (worst case this is a leak, which is bad but is usually a little better than a dangling pointer). This hole could be plugged by declaring FredPtr::operator new() as private, thus preventing someone from saying new FredPtr(). Another hole here is if someone creates a local FredPtr object, then takes the address of that FredPtr and passed around the FredPtr*. If that FredPtr* lived longer than the FredPtr, you could have a dangling pointer — shudder. This hole could be plugged by preventing people from taking the address of a FredPtr (by overloading FredPtr::operator&() as private), with the corresponding loss of functionality. But even if you did all that, they could still create a FredPtr& which is almost as dangerous as a FredPtr*, simply by doing this: FredPtr p; ... FredPtr& q = p; (or by passing the FredPtr& to someone else).

And even if we closed all those holes, C++ has those wonderful pieces of syntax called pointer casts. Using a pointer cast or two, a sufficiently motivated programmer can normally create a hole that's big enough to drive a proverbial truck through. (By the way, pointer casts are evil.)

So the lessons here seems to be: (a) you can't prevent espionage no matter how hard you try, and (b) you can easily prevent mistakes.

So I recommend settling for the "low hanging fruit": use the easy-to-build and easy-to-use mechanisms that prevent mistakes, and don't bother trying to prevent espionage. You won't succeed, and even if you do, it'll (probably) cost you more than it's worth.

So if we can't use the C++ language itself to prevent espionage, are there other ways to do it? Yes. I personally use old fashioned code reviews for that. And since the espionage techniques usually involve some bizarre syntax and/or use of pointer-casts and unions, you can use a tool to point out most of the "hot spots."

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

Yes.

Compared with the "smart pointer" techniques (see [16.22], the two kinds of garbage collector techniques (see [16.27]) are:

• less portable
• usually more efficient (especially when the average object size is small or in multithreaded environments)
• able to handle "cycles" in the data (reference counting techniques normally "leak" if the data structures can form a cycle)
• sometimes leak other objects (since the garbage collectors are necessarily conservative, they sometimes see a random bit pattern that appears to be a pointer into an allocation, especially if the allocation is large; this can allow the allocation to leak)
• work better with existing libraries (since smart pointers need to be used explicitly, they may be hard to integrate with existing libraries)

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

In general, there seem to be two flavors of garbage collectors for C++:

1. Conservative garbage collectors. These know little or nothing about the layout of the stack or of C++ objects, and simply look for bit patterns that appear to be pointers. In practice they seem to work with both C and C++ code, particularly when the average object size is small. Here are some examples, in alphabetical order:

   • Boehm-Demers-Weiser collector
   • Geodesic Systems collector

2. Hybrid garbage collectors. These usually scan the stack conservatively, but require the programmer to supply layout information for heap objects. This requires more work on the programmer's part, but may result in improved performance. Here are some examples, in alphabetical order:

   • Attardi and Flagella's CMM
   • Bartlett's mostly copying collector

Since garbage collectors for C++ are normally conservative, they can sometimes leak if a bit pattern "looks like" it might be a pointer to an otherwise unused block. Also they sometimes get confused when pointers to a block actually point outside the block's extent (which is illegal, but some programmers simply must push the envelope; sigh) and (rarely) when a pointer is hidden by a compiler optimization. In practice these problems are not usually serious, however providing the collector with hints about the layout of the objects can sometimes ameliorate these issues.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

For more information, see the Garbage Collector FAQ.

[ Top | Bottom | Previous section | Next section | Search the FAQ ]

 E-mail the author
[ C++ FAQ Lite | Table of contents | Subject index | About the author | © | Download your own copy ]
Revised Mar 1, 2006