inconsistent behavior with user-defined new and delete

[jeffjohnson_alpha]

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?

my_pool pool ;
foo* a = new(pool) foo() ;

// compile error
delete(pool) a ;

// calls the default operator delete(), not our delete
delete a ;

// does not call foo::~foo()
::operator delete(a, pool) ;

// is this the idiom, then?
a->~foo() ;
::operator delete(a, pool) ;

There appears to be no such delete-expression to complement the
new-expression. Why the inconsistency? Surely this is an oversight
in the design of C++? In particular I expected "delete(poo l) a" to
work.

To recap, we have a mechanism for default-allocate-then-construct
(no-argument new-expressions) and for destruct-then-default-deallocate
(no-argument delete-expressions). Furthermore, we have a mechanism
for custom-allocate-then-construct (custom new-expressions), but NOT
for destruct-then-custom-deallocate (no custom delete-expressions).

One workaround is to define operator new() and operator delete()
inside foo, but suppose I can't do that. Another workaround is to use

template< typename pool_type, typename T >
void custom_delete( pool_type & pool, T* p )
{
p->~T() ;
pool.deallocate (p, sizeof(T)) ;
}

but this just begs the question of why that should be necessary, i.e.,
why no delete-expressions, i.e. delete(pool) p.

Incidentally this begs a more general question: since a custom
operator new() defined outside of a class will not work with auto_ptr,
one wonders what is the point of such operator new()s. Surely someone
will eventually use auto_ptr with it by accident, wreaking havoc when
the wrong delete is called from auto_ptr::~auto _ptr(). This seems to
suggest that "delete p" should automagically call

void operator delete( void* data, my_pool & ) throw() ;

however that is probably impossible to implement efficiently (relative
to current C++ implementations ). Another option is for the auto_ptr
constructor to take an optional (de)allocator but that relies on
programmers remembering to do so, which doesn't solve the problem but
just moves it around.

#include <iostream>
#include <ostream>

class my_pool
{
} ;

void* operator new( std::size_t size, my_pool & )
throw(std::bad_ alloc)
{
std::cerr << "my_pool operator new" << std::endl ;
return ::operator new(size) ;
}

void operator delete( void* data, my_pool & ) throw()
{
std::cerr << "my_pool operator delete" << std::endl ;
return ::operator delete(data) ;
}

struct foo
{
foo()
{
std::cerr << "foo::foo() " << std::endl ;
}

~foo()
{
std::cerr << "foo::~foo( )" << std::endl ;
}
} ;

int main()
{
my_pool pool ;

foo* a = new(pool) foo() ;

// compile error
//delete(pool) a ;

// calls the default operator delete(), not ours
//delete a ;

// does not call foo::~foo()
//::operator delete(a, pool) ;

// is this the idiom, then?
a->~foo() ;
::operator delete(a, pool) ;

return 0 ;
}

[Sylvester Hesp]

je************* **@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?

Not possible using the delete operator. However, do note that a
placement delete counterpart for operator new is needed in the case
that an exception is thrown during object construction, in which case
it is automatically called to clean up the memory.

One workaround is to define operator new() and operator delete()
inside foo, but suppose I can't do that. Another workaround is to use

template< typename pool_type, typename T >
void custom_delete( pool_type & pool, T* p )
{
p->~T() ;
pool.deallocate (p, sizeof(T)) ;
}

Another one is to override the global operator delete, where your
placement new somehow associates the allocator with the allocated chunk
of memory, and the delete fetches the appropriate allocator and uses it
to free the memory.

- Sylvester

[jeffjohnson_alpha]

On May 30, 10:40 am, Sylvester Hesp <s.hes...@SPAMo isyn.nlwrote:

>
Not possible using the delete operator. However, do note that a
placement delete counterpart for operator new is needed in the case
that an exception is thrown during object construction, in which case
it is automatically called to clean up the memory.

[...]

Another one is to override the global operator delete, where your
placement new somehow associates the allocator with the allocated chunk
of memory, and the delete fetches the appropriate allocator and uses it
to free the memory.

I don't know if this was a misunderstandin g or not, but I wasn't using
placement new. I was using an overloaded operator new(). My
new-expression is "new(pool) foo()", whereas placement new is
"new(&pool) foo()".

[Alf P. Steinbach]

* je************* **@yahoo.com:

On May 30, 10:40 am, Sylvester Hesp <s.hes...@SPAMo isyn.nlwrote:

>Not possible using the delete operator. However, do note that a
placement delete counterpart for operator new is needed in the case
that an exception is thrown during object construction, in which case
it is automatically called to clean up the memory.

[...]

Another one is to override the global operator delete, where your
placement new somehow associates the allocator with the allocated chunk
of memory, and the delete fetches the appropriate allocator and uses it
to free the memory.

I don't know if this was a misunderstandin g or not, but I wasn't using
placement new. I was using an overloaded operator new(). My
new-expression is "new(pool) foo()", whereas placement new is
"new(&pool) foo()".

The misunderstandin g is on your part: you're using placement new.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Sylvester Hesp]

je************* **@yahoo.com wrote :

On May 30, 10:40 am, Sylvester Hesp <s.hes...@SPAMo isyn.nlwrote:

>>
Not possible using the delete operator. However, do note that a
placement delete counterpart for operator new is needed in the case
that an exception is thrown during object construction, in which case
it is automatically called to clean up the memory.

[...]

Another one is to override the global operator delete, where your
placement new somehow associates the allocator with the allocated chunk
of memory, and the delete fetches the appropriate allocator and uses it
to free the memory.

I don't know if this was a misunderstandin g or not, but I wasn't using
placement new. I was using an overloaded operator new(). My
new-expression is "new(pool) foo()", whereas placement new is
"new(&pool) foo()".

There was no misunderstandin g from my part, any "overloaded operator
new()", as you call it, is called placement new - not only the one that
takes a void* and returns that very pointer ;)

- Sylvester

[jeffjohnson_alpha]

On May 30, 11:19 am, "Alf P. Steinbach" <[e-mail] rote:

* jeffjohnson_al. [e-mail]:

I don't know if this was a misunderstandin g or not, but I wasn't using
placement new. I was using an overloaded operator new(). My
new-expression is "new(pool) foo()", whereas placement new is
"new(&pool) foo()".

The misunderstandin g is on your part: you're using placement new.

new(&pool) foo() calls

void* operator new( std::size_t, void* ) throw() ;

new(pool) foo() calls

void* operator new( std::size_t, my_pool & ) throw(bad_alloc ) ;

If both are called "placement new", then how do we differentiate
between them? The former places the object at the given address,
while the latter can do something else entirely.

By attempting to clarify what looked like a misunderstandin g, I've
inadvertently committed a sin of terminology. I hope the discussion
doesn't get sidetracked due of my linguistic immorality.

[Pete Becker]

je************* **@yahoo.com wrote:

>
new(&pool) foo() calls

void* operator new( std::size_t, void* ) throw() ;

new(pool) foo() calls

void* operator new( std::size_t, my_pool & ) throw(bad_alloc ) ;

If both are called "placement new", then how do we differentiate
between them? The former places the object at the given address,
while the latter can do something else entirely.

The latter does exactly the same thing as the former: it calls an
overloaded version of operator new. The name for that usage is
"placement new."

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[jeffjohnson_alpha]

On May 30, 12:04 pm, Pete Becker <p...@versatile coding.comwrote :

jeffjohnson_al. [e-mail] wrote:

new(&pool) foo() calls

void* operator new( std::size_t, void* ) throw() ;

new(pool) foo() calls

void* operator new( std::size_t, my_pool & ) throw(bad_alloc ) ;

If both are called "placement new", then how do we differentiate
between them? The former places the object at the given address,
while the latter can do something else entirely.

The latter does exactly the same thing as the former: it calls an
overloaded version of operator new. The name for that usage is
"placement new."

Yes, and I've already openly admitted my sin of terminology, the part
which you clipped. I shall admit this once again, even though you may
clip that and correct me again. Please forgive me.

My question is still valid, however. If both are called placement
new, then what do I say when I mean this

new(&buffer) foo() ;

and what do I say when I mean this

new(debug_alloc ) foo() ;

Obviously I can't just say "placement new" for both. In practice,
when one says "placement new", one usually means placing the object at
the given address, i.e. the former. In particular I bet most C++
programmers would say "placement new" for the first one and something
like "new with debug_alloc" for the second one. "Placement new with
debug_alloc" is likely to cause confusion.

If I may assess the situation, it appears that you wish to be pedantic
about what is correct terminology, while I wish to be practical about
what is clear and unambiguous terminology.

[Alf P. Steinbach]

* je************* **@yahoo.com:

On May 30, 12:04 pm, Pete Becker <p...@versatile coding.comwrote :

>jeffjohnson_al [e-mail] wrote:

>>new(&pool) foo() calls
void* operator new( std::size_t, void* ) throw() ;
new(pool) foo() calls
void* operator new( std::size_t, my_pool & ) throw(bad_alloc ) ;
If both are called "placement new", then how do we differentiate
between them? The former places the object at the given address,
while the latter can do something else entirely.

The latter does exactly the same thing as the former: it calls an
overloaded version of operator new. The name for that usage is
"placement new."

Yes, and I've already openly admitted my sin of terminology, the part
which you clipped. I shall admit this once again, even though you may
clip that and correct me again. Please forgive me.

My question is still valid, however. If both are called placement
new, then what do I say when I mean this

new(&buffer) foo() ;

and what do I say when I mean this

new(debug_alloc ) foo() ;

Obviously I can't just say "placement new" for both. In practice,
when one says "placement new", one usually means placing the object at
the given address, i.e. the former. In particular I bet most C++
programmers would say "placement new" for the first one and something
like "new with debug_alloc" for the second one. "Placement new with
debug_alloc" is likely to cause confusion.

If I may assess the situation, it appears that you wish to be pedantic
about what is correct terminology, while I wish to be practical about
what is clear and unambiguous terminology.

Well, it's not a big deal, except there was a misunderstandin g between
you and someone else higher up in the thread.

Yes, the term "placement" stems from the placement usage, placing an
object at (or is it that "in"? correct me!) some pre-existing storage.

If you want you can call the placement new operator from the <new>
header, a pure placement new or the standard library's placement new.

Hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[James Kanze]

On May 30, 5:56 pm, jeffjohnson_al. [e-mail] wrote:

[...]

new(&pool) foo() calls

void* operator new( std::size_t, void* ) throw() ;

new(pool) foo() calls

void* operator new( std::size_t, my_pool & ) throw(bad_alloc ) ;

If both are called "placement new", then how do we differentiate
between them?

With difficulty:-).

In section §5.3.4 (the description of the new operator), the
standard clearly includes both of these under the name
"placement new". In section §18.5.1.3 (the description of the
placement operator new function in the library), it just as
clearly only consideres the first under the term "placement
new".

In the end, I can't think of anything better that "standard
placement new" and "user-defined placement new". But we really
need a different name for the "placement syntax" described in
§5.3.4, since it really is a misnomer.

The former places the object at the given address,
while the latter can do something else entirely.

By attempting to clarify what looked like a misunderstandin g,
I've inadvertently committed a sin of terminology.

Join the club. The authors of the library section of the
standard didn't do any better.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]