Re: inconsistent behavior with user-defined new and delete
On May 30, 2:15 pm, jeffjohnson_al...@yahoo.com wrote:
We all know that a new-expression,
foo* a = new foo() ;
allocates memory for a single foo then calls foo::foo(). And we know
that
void* p = ::operator new(sizeof(foo)) ;
allocates a sizeof(foo)-sized buffer but does NOT call foo::foo().
So only new-expressions both allocate and initialize. Fair enough.
Now suppose we wish to use a custom memory pool,
my_pool pool ;
foo* a = new(pool) foo() ;
This calls
void* operator new( std::size_t size, my_pool & )
throw(std::bad_alloc) ;
and then calls foo::foo(). Naturally we also define
void operator delete( void* data, my_pool & ) throw() ;
But how are we going to call our custom delete?
By throwing an exception in the constructor of foo:-).
Seriously, any time you add a user defined placement new, you
also have to overload the non-placement forms, in order to
memorize which new was used, and dispatch correctly in the
delete. Something like the following:
union MemHdr
{
Pool* owner ;
double forAlignment ;
} ;
void*
operator new( size_t n ) throw ( std::bad_alloc )
{
MemHdr* p = (MemHdr*)malloc( n + sizeof( MemHdr ) ) ;
while ( p == NULL ) {
std::new_handler h = set_new_handler( NULL ) ;
if ( h == NULL )
throw std::bad_alloc() ;
} else {
set_new_handler( h ) ;
(*h)() ;
p = (MemHdr*)malloc( n + sizeof( MemHdr ) ) ;
}
}
p->owner = NULL ;
return p + 1 ;
}
void*
operator new( size_t n, Pool& pool ) throw( std::bad_alloc )
{
MemHdr* p = (MemHdr*)pool.alloc( n + sizeof( MemHdr ) ) ;
while ( p == NULL ) {
std::new_handler h = set_new_handler( NULL ) ;
if ( h == NULL )
throw std::bad_alloc() ;
} else {
set_new_handler( h ) ;
(*h)() ;
p = (MemHdr*)pool.alloc( n + sizeof( MemHdr ) ) ;
}
}
p->owner = &pool ;
return p + 1 ;
}
void
operator delete( void* userPtr )
{
MemHdr* p = (MemHdr*)userPtr - 1 ;
if ( p-owner == NULL ) {
free( p ) ;
} else {
p->owner->free( p ) ;
}
}
void
operator delete( void* userPtr, Pool& pool )
{
pool.free( (MemHdr*)userPtr - 1 ) ;
}
Note that you'll need some locking in the operator new if
you're in a multithreaded environment. A scoped lock at the top
of the loop should be sufficient.
Note too that the standard guarantees that malloc does not call
operator new, so you can safely use it. The standard does NOT
guarantee that bad_alloc::bad_alloc or set_new_handler do NOT
call the operator new function, so you'll just have to cross
your fingers on those. Or count on quality of
implementation---I think we can agree that it would be a very,
very poor implementation were either of these did call the
operator new function. (In practice, I've also used functions
like memset or std::fill_n in my implementations of operator
new. Without any problems, although, again, the standard makes
no guarantees. I've also output to std::cerr, but in such
cases, I take particular precautions against recursive calls.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34