TITLE: operator new versus new xxx


PROBLEM: Tendrils@msn.com (kelvin  )

Your overridden new may be hiding the global new .... which explain 
why it works when you revert back .... try this (from effective c++ 
by Scott Meyers)...

In the test class, add this function

void *operator new(size_t size)
{ return ::new char[size];}


RESPONSE: smeyers@netcom.com (Scott Meyers), 8 Feb 96

Better yet, write this function the way I *should* have written it in
Effective C++:

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

On most machines, the two implementations will behave the same, but it is
possible that the former will fail to satisfy alignment restrictions and
the latter will not.

For more information on the difference between "new char[...]" and a call
to "operator new," you might check out Item 8 in my new book, "More
Effective C++."


RESPONSE: clarke@ses.com

[...]

Could you give me a very brief explaination as to the
differences between the two?

[...]


RESPONSE: Scott Meyers <smeyers@netcom.com>

The fundamental deal is this.  When you say:

  new TYPE
  
you are calling the new operator.  That operator is built into the
language and you cannot change its behavior.  It always does the
following two things:

  1.  Allocate enough memory for a TYPE object.
  2.  Invoke a TYPE constructor to initialize the memory.
  
The way it accomplishes step 1 is to call some function called operator
new.  That function, which you may write, is responsible for nothing
more than allocation of raw memory.

In short:

  class Foo{ ... };
  
  void *memory = operator new(sizeof(Foo));   // allocate enough raw memory
                                              // to hold a Foo, but
                                              // don't put anything in the
                                              // memory 

  Foo *pFoo = new Foo;   // allocate enough raw memory to hold a Foo,
                         // then invoke a Foo constructor to initialize
                         // the memory

In my example in Effective C++, the matter is muddied further by my
allocation of an array of chars instead of a block of raw memory.  This
likely leads to undefined behavior, because array allocation is handled
differently than single-object allocation.  Sigh.  I won't have a
chance to fix this until I rewrite Effective C++, and I don't plan to
do that for a while.