Prefer new and delete to malloc and free.

Item 3: Prefer new and delete to malloc and free.
The problem with malloc and free (and their variants) is simple: they don't know about constructors and
destructors.
Consider the following two ways to get space for an array of 10 string objects, one using malloc, the other using
new:
string *stringArray1 =
static_cast(malloc(10 * sizeof(string)));
string *stringArray2 = new string[10];
Here stringArray1 points to enough memory for 10 string objects, but no objects have been constructed in that
memory. Furthermore, without jumping through some rather obscure linguistic hoops (such as those described in
Items M4 and M8), you have no way to initialize the objects in the array. In other words, stringArray1 is pretty
useless. In contrast, stringArray2 points to an array of 10 fully constructed string objects, each of which can
safely be used in any operation taking a string.
Nonetheless, let's suppose you magically managed to initialize the objects in the stringArray1 array. Later on in
your program, then, you'd expect to do this:
free(stringArray1);
delete [] stringArray2;
// see Item 5 for why the
// "[]" is necessary
The call to free will release the memory pointed to by stringArray1, but no destructors will be called on the
string objects in that memory. If the string objects themselves allocated memory, as string objects are wont to do,
all the memory they allocated will be lost. On the other hand, when delete is called on stringArray2, a destructor
is called for each object in the array before any memory is released.
Because new and delete interact properly with constructors and destructors, they are clearly the superior
choice.
Mixing new and delete with malloc and free is usually a bad idea. When you try to call free on a pointer you got
from new or call delete on a pointer you got from malloc, the results are undefined, and we all know what
"undefined" means: it means it works during development, it works during testing, and it blows up in your most
important customers' faces.
The incompatibility of new/delete and malloc/free can lead to some interesting complications. For example, the
strdup function commonly found in takes a char*-based string and returns a copy of it:
char * strdup(const char *ps);
// return a copy of what
// ps points to
At some sites, both C and C++ use the same version of strdup, so the memory allocated inside the function
comes from malloc. As a result, unwitting C++ programmers calling strdup might overlook the fact that they must
use free on the pointer returned from strdup. But wait! To forestall such complications, some sites might decide
to rewrite strdup for C++ and have this rewritten version call new inside the function, thereby mandating that
callers later use delete. As you can imagine, this can lead to some pretty nightmarish portability problems as
code is shuttled back and forth between sites with different forms of strdup.
Still, C++ programmers are as interested in code reuse as C programmers, and it's a simple fact that there are
lots of C libraries based on malloc and free containing code that is very much worth reusing. When taking
advantage of such a library, it's likely you'll end up with the responsibility for freeing memory malloced by the
library and/or mallocing memory the library itself will free. That's fine. There's nothing wrong with calling
malloc and free inside a C++ program as long as you make sure the pointers you get from malloc always meet
their maker in free and the pointers you get from new eventually find their way to delete. The problems start
when you get sloppy and try to mix new with free or malloc with delete. That's just asking for trouble.