Why no placement delete?
Andy Venikov
I know you can define your own placement operator delete, but it will
only be called in case a constructor throws an exception when placement
new is called. You can't call placement delete directly.
This limitation greatly impairs the use of custom allocators.
For example, if you want you allocations to come from a specific memory
region and you have a handle to that region you can: (assuming
regionAllocator is an object of a custom RegionAllocator class)
X * px = new (regionAllocator) X;
But you can't
delete (regionAllocator) px;
you can only
delete px;
That puts an unduly difficult requirement on (presumably custom)
operator delete to figure out where the memory came from. And no, it's
not always possible to embed that information with the returned memory.
The only rational I can think of is the ability to destroy any object by
just having a pointer to it, which would make generic destructors a bit
easy. But in my view this is a draconian requirement.
Thanks,
Andy.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Seungbeom Kim
> What's the rational for not having placement delete?
It's answered in
<http://www2.research.att.com/~bs/bs_faq2.html#placement-delete>:
'The reason that there is no built-in "placement delete" to
match placement new is that there is no general way of assuring
that it would be used correctly.'
though I think "placement delete" could still have been possible:
we still have the dereference operator even though we have no general
way of assuring that the pointer points to a valid object.
> This limitation greatly impairs the use of custom allocators.
>
> For example, if you want you allocations to come from a specific memory
> region and you have a handle to that region you can: (assuming
> regionAllocator is an object of a custom RegionAllocator class)
>
> X * px = new (regionAllocator) X;
>
>
> But you can't
>
> delete (regionAllocator) px;
>
> you can only
>
> delete px;
As suggested in the FAQ above, the correct way would be
if (px) {
px->~X();
regionAllocator.deallocate(px);
}
--
Seungbeom Kim
restor
C++ has a placement delete it is just spelled differently: I believe
explicit destructor call. Consider an example:
void createAndDestroy( Class * obj )
{
new (obj) Class("obj1"); // ctor w/o allocation
obj->~Class(); // dtor w/o deallocation
}
I think the naming convention is confusing, as this question reoccurs
time and again. And it is the "placement new" that is confusing, as it
implies special (trivial) form of allocation. They probably should be
called "explicit constructor call" and "explicit destructor call".
Regards,
&rzej
Thomas Richter
> What's the rational for not having placement delete?
Because it is too application specific as what it should do. A placement
new, in its original and intentional form, places an object in a
memory location reserved by some means outside of the control of the
operator new itself, which means that a placement delete cannot, by
symmetry, release the memory of which the new didn't know how it was
allocated. Instead, you would call the destructor of the object
directly, and then release the memory manually similar to the way how
you allocated the memory manually to place the object in.
> This limitation greatly impairs the use of custom allocators.
This is a quite different use of the operator new "with parameters".
Here, instead of using the parameter to indicate the memory region where
to allocate the object in - the original intent of the specs - you use
the parameter to specify a "memory pool" to allocate the object from.
Strictly speaking, this is not a "placement new" but a "new with
parameters".
> For example, if you want you allocations to come from a specific memory
> region and you have a handle to that region you can: (assuming
> regionAllocator is an object of a custom RegionAllocator class)
>
> X * px = new (regionAllocator) X;
>
>
> But you can't
>
> delete (regionAllocator) px;
>
> you can only
>
> delete px;
Which is usually sufficient. What you can do (or what I typically do) is
to store the memory pool you allocated the object from along with the
object itself, in the allocated memory. Then, operator delete locates
this memory pool and releases the memory itself in that pool.
One way of doing that would be to provide custom operator new's (with
parameters) and custom operator delete's for the classes you would like
to pool-allocate.
> That puts an unduly difficult requirement on (presumably custom)
> operator delete to figure out where the memory came from. And no, it's
> not always possible to embed that information with the returned memory.
Why not? Please provide more details. Always worked for me.
> The only rational I can think of is the ability to destroy any object by
> just having a pointer to it, which would make generic destructors a bit
> easy. But in my view this is a draconian requirement.
I would rather say that it is a historic accident, namely that operator
new with parameters is actually intended for something different than a
"memory pool" allocation, namely a "placement new". And in that
situation, you simply don't need a "placement delete" because you have
to always destroy the object manually - and releasing the memory is as
much out of the scope of operator delete as it was for the corresponding
placement new.
Thus, I would believe the intended (but unpractical) use of memory pools
would rather be:
mem = pool->Allocate(sizeof(Object))
object = new(mem) Object;
and, quite symmetric to the above:
object->~Object();
pool->Release(object);
instead of the (nicer to read)
object = new(pool) Object;
delete object;
So long,
Thomas
Goran Pusic
> What's the rational for not having placement delete?
>
> I know you can define your own placement operator delete, but it will
> only be called in case a constructor throws an exception when placement
> new is called. You can't call placement delete directly.
Yes. I think this is OK WRT the idea behind: if you use default
operator new, then if constructor throws, runtime knows how to free
allocated memory. When you overload operator new, though, it's your
job to react to that exception from constructor, because only you know
the meaning of your new.
But note that placement new is often used to construct the object from
existing already available memory, so delete ain't needed at all. I
guess that's why it's optional.
>
> This limitation greatly impairs the use of custom allocators.
>
> For example, if you want you allocations to come from a specific memory
> region and you have a handle to that region you can: (assuming
> regionAllocator is an object of a custom RegionAllocator class)
>
> X * px = new (regionAllocator) X;
>
> But you can't
>
> delete (regionAllocator) px;
>
> you can only
>
> delete px;
>
> That puts an unduly difficult requirement on (presumably custom)
> operator delete to figure out where the memory came from. And no, it's
> not always possible to embed that information with the returned memory.
Ahhh, but if you allocate instances of your class both from standard
heap and your own allocator, are these still the same class? If
nothing else, they are not the same WRT that particular detail that is
heap handling.
If that is the case, you could have variants of your class: base (with
actual functionality), one where you use default allocation and one
that comes from a pool. Then you pass reference to base around for
work, and call operator delete (compiler picks correct one for you)
when it's time to go.
You should note that operator new and delete must "reverse-match" ;-)
in functionality for a given class instance. Even if what you want to
do was possible, you would still have to keep track of how a
particular instance was instantiated so that you can call appropriate
delete version. And if that is so, you could just as well split your
instances in two actual classes and be done with it. In other words,
it seems that you don't gain much (if anything) with your idea.
Goran.
Ulrich Eckhardt
> What's the rational for not having placement delete?
>
> I know you can define your own placement operator delete, but it will
> only be called in case a constructor throws an exception when placement
> new is called. You can't call placement delete directly.
>
> This limitation greatly impairs the use of custom allocators.
Wait: Placement new only constructs the object, it doesn't do any
allocation. Where the memory for the object came from is basically
irrelevant there. In that light, I'm also not really sure I understand
your problem and whether the advise below is really relevant to it.
> For example, if you want you allocations to come from a specific memory
> region and you have a handle to that region you can: (assuming
> regionAllocator is an object of a custom RegionAllocator class)
>
> X * px = new (regionAllocator) X;
>
>
> But you can't
>
> delete (regionAllocator) px;
>
> you can only
>
> delete px;
You can also
px->~X();
i.e. directly invoke the destructor. This is generally use as complementary
to placement new.
Uli
--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
Francis Glassborow
> What's the rational for not having placement delete?
>
> I know you can define your own placement operator delete, but it will
> only be called in case a constructor throws an exception when placement
> new is called. You can't call placement delete directly.
>
> This limitation greatly impairs the use of custom allocators.
>
> For example, if you want you allocations to come from a specific memory
> region and you have a handle to that region you can: (assuming
> regionAllocator is an object of a custom RegionAllocator class)
>
> X * px = new (regionAllocator) X;
>
>
> But you can't
>
> delete (regionAllocator) px;
>
> you can only
>
> delete px;
bu you can also write
px -> ~X();
Which is really the reason that placement delete is restricted to
dealing with cases where a ctor throws. It was introduced exactly
because there was a problem in that case (the compiler has to know what
the user wants to do if construction as a result of a class member
placement new fails by throwing an exception.
>
>
> That puts an unduly difficult requirement on (presumably custom)
> operator delete to figure out where the memory came from. And no, it's
> not always possible to embed that information with the returned memory.
No. You just call the dtor explicitly and then, if necessary (though it
usually isn't) call an appropriate over;load of operator delete
explicitly. IOWs decouple destruction from memory management.
Stuart Golodetz
> What's the rational for not having placement delete?
>
> I know you can define your own placement operator delete, but it will
> only be called in case a constructor throws an exception when placement
> new is called. You can't call placement delete directly.
>
> This limitation greatly impairs the use of custom allocators.
>
> For example, if you want you allocations to come from a specific memory
> region and you have a handle to that region you can: (assuming
> regionAllocator is an object of a custom RegionAllocator class)
>
> X * px = new (regionAllocator) X;
>
>
> But you can't
>
> delete (regionAllocator) px;
>
> you can only
>
> delete px;
>
>
> That puts an unduly difficult requirement on (presumably custom)
> operator delete to figure out where the memory came from. And no, it's
> not always possible to embed that information with the returned memory.
>
>
> The only rational I can think of is the ability to destroy any object by
> just having a pointer to it, which would make generic destructors a bit
> easy. But in my view this is a draconian requirement.
>
>
> Thanks,
> Andy.
I hope I'm not missing the point of your question here, but can't you
just do:
px->~X()
?
I don't use placement new all that often, but off the top of my head I
seem to remember the idea being something like this:
#include <memory>
#include <string>
int main()
{
using std::string;
void *mem = ::operator new(sizeof(string));
string *s = new (mem) string;
*s = "Wibble";
s->~string();
::operator delete(mem);
return 0;
}
In other words, the explicit destructor call destroys the string
constructed by placement new. So you have to know that your string was
allocated by placement new, sure, but this isn't really any different
from having to know that your pointer points to an array rather than a
single object (which also changes the syntax at the point of destruction
- from delete to delete[]).
Or are you asking something more subtle?
Best wishes,
Stu
Hyman Rosen
> (you can)
> X * px = new (regionAllocator) X;
> But you can't
> delete (regionAllocator) px;
> you can only
> delete px;
Just do
px->~X();
regionAllocator.free(px);
Andy Venikov
> Andy Venikov wrote:
>> (you can)
>> X * px = new (regionAllocator) X;
>> But you can't
>> delete (regionAllocator) px;
>> you can only
>> delete px;
>
> Just do
> px->~X();
> regionAllocator.free(px);
>
Yes, this is what I'm forced to do. But it looks ugly that for a single
new you actually need two calls. In my case I just created a templated
"Destruct" function that does both.
Thanks,
Andy.
Andy Venikov
>>
>> That puts an unduly difficult requirement on (presumably custom)
>> operator delete to figure out where the memory came from. And no, it's
>> not always possible to embed that information with the returned memory.
>
> Ahhh, but if you allocate instances of your class both from standard
> heap and your own allocator, are these still the same class? If
> nothing else, they are not the same WRT that particular detail that is
> heap handling.
Well, I don't want my types to be aware of actual physical memory
placement. The same type can be allocated on the heap or anywhere else
and that doesn't change the type's type.
>
> If that is the case, you could have variants of your class: base (with
> actual functionality), one where you use default allocation and one
> that comes from a pool. Then you pass reference to base around for
> work, and call operator delete (compiler picks correct one for you)
> when it's time to go.
That would add virtual dispatch to classes that whouldn't need it otherwise.
>
> You should note that operator new and delete must "reverse-match" ;-)
> in functionality for a given class instance. Even if what you want to
> do was possible, you would still have to keep track of how a
> particular instance was instantiated so that you can call appropriate
> delete version. And if that is so, you could just as well split your
> instances in two actual classes and be done with it. In other words,
> it seems that you don't gain much (if anything) with your idea.
Hmmm, knowledge of what argument to use when calling delete can be
gained statically, without the need to revert to virtual dispatch.
Andy Venikov
>> What's the rational for not having placement delete?
>
> C++ has a placement delete it is just spelled differently: I believe
> explicit destructor call. Consider an example:
>
> void createAndDestroy( Class * obj )
> {
> new (obj) Class("obj1"); // ctor w/o allocation
> obj->~Class(); // dtor w/o deallocation
> }
>
> I think the naming convention is confusing, as this question reoccurs
> time and again. And it is the "placement new" that is confusing, as it
> implies special (trivial) form of allocation. They probably should be
> called "explicit constructor call" and "explicit destructor call".
>
> Regards,
> &rzej
>
I believe you've misunderstood my point.
I was talking about a general form of placement new, the one that takes
any user-defined type, not just a pointer to void. You assumed that I
was talking about a version of placement new that was taking a pointer
to void. According to the standard it is not even possible to overload
this function and yes, all it does is calls a constructor in the
specified memory.
Andy.
Francis Glassborow
> Andy Venikov wrote:
>> What's the rational for not having placement delete?
>>
>> I know you can define your own placement operator delete, but it will
>> only be called in case a constructor throws an exception when placement
>> new is called. You can't call placement delete directly.
>>
>> This limitation greatly impairs the use of custom allocators.
>
> Wait: Placement new only constructs the object, it doesn't do any
> allocation. Where the memory for the object came from is basically
> irrelevant there. In that light, I'm also not really sure I understand
> your problem and whether the advise below is really relevant to it.
Except that with the complete ineptitude in naming in this part of C++,
placement new is normally taken to refer to any version of operator new
that takes parameters not just the one where you provide the memory
directly.
--
Andy Venikov
Sorry, it looks like there's some confusion with terminology.
What I was talking about is operator new that takes any user-defined
type (and any number of them). I believe it is called a placement-new
operator, with the version that takes void * being just a special case
of it.
Some people call it "a new with parameters".
peter koch larsen
> Goran Pusic wrote:
>
[snip]
> > You should note that operator new and delete must "reverse-match" ;-)
> > in functionality for a given class instance. Even if what you want to
> > do was possible, you would still have to keep track of how a
> > particular instance was instantiated so that you can call appropriate
> > delete version. And if that is so, you could just as well split your
> > instances in two actual classes and be done with it. In other words,
> > it seems that you don't gain much (if anything) with your idea.
>
> Hmmm, knowledge of what argument to use when calling delete can be
> gained statically, without the need to revert to virtual dispatch.
>
program analysis (and this often is practically not possible) you
could have cases such is:
void f(volatile bool b)
{
int* val = b ? new int(1): new(myallocator) int(2);
...
// how to delete here?
}
/Peter
Martin B.
> Hyman Rosen wrote:
>> Andy Venikov wrote:
>>> (you can)
>>> X * px = new (regionAllocator) X;
>>> But you can't
>>> delete (regionAllocator) px;
>>> you can only
>>> delete px;
>>
>> Just do
>> px->~X();
>> regionAllocator.free(px);
>>
>
> Yes, this is what I'm forced to do. But it looks ugly that for a single
> new you actually need two calls. In my case I just created a templated
> "Destruct" function that does both.
>
I agree it's ugly, but so is the placement-new syntax IMHO (the explicit
dtor call is just even more ugly).
If I were faced with such (which I have never been yet) I would prefer
to use some more machinery to hide all that new and placement stuff
between some interface.
Personally I think new-with-parameter is just something that's better
and more clearly done with a named function (except for the void* case,
as we already have that operator-new).
I have done a simple scratch program below.
br,
Martin
[CODE]
#include "stdafx.h"
#include <boost/smart_ptr.hpp>
#include "unique_ptr.hpp" // from
http://home.roadrunner.com/~hinnant/unique_ptr03.html
#include <string>
#include <iostream>
using namespace std;
using namespace boost;
struct X {
string m_;
X() {
// throw runtime_error("Check that ctor exceptions are handled
correctly.");
}
};
struct destruct_X {
void operator()(X* obj) {
if(obj) {
obj->~X();
free(obj);
}
}
};
//! create a new X object in a custom memory pool
//! The knowledge of how to delete the object is already encapsulated
//! in the shared_ptr instance.
shared_ptr<X> construct_shared_x() {
void* p = malloc(sizeof(X));
if(!p)
throw bad_alloc("struct X");
try {
return shared_ptr<X>( new (p) X, destruct_X() );
} catch(...) {
free(p);
throw;
}
}
//! create a new X object in a custom memory pool
//! The Unique pointer takes care of deallocating it correctly, but
//! if you absolutely want to, you can call release() on the
//! returned uptr to manually manage the raw ptr.
typedef unique_ptr<X, destruct_X> PooledXPtr;
PooledXPtr construct_unique_x() {
void* p = malloc(sizeof(X));
if(!p)
throw bad_alloc("struct X");
try {
return PooledXPtr( new (p) X );
} catch(...) {
free(p);
throw;
}
}
int main(int argc, char* argv[])
{
// Dump leaked memory (Windows specific)
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
try {
shared_ptr<X> px = construct_shared_x();
px->m_ = "Shared!";
cout << px->m_ << "\n";
} catch(...) {
cout << "Failed shared.\n";
}
try {
PooledXPtr ux = construct_unique_x();
ux->m_ = "Unique!";
cout << ux->m_ << "\n";
} catch(...) {
cout << "Failed unique.\n";
}
try {
X* x = construct_unique_x().release();
x->m_ = "Raw!";
cout << x->m_ << "\n";
destruct_X()(x);
} catch(...) {
cout << "Failed raw.\n";
}
return 0;
Andy Venikov
> On 4 Dec., 19:56, Andy Venikov <swojchelo...@gmail.com> wrote:
>
Hmmm, knowledge of what argument to use when calling delete can be
>> gained statically, without the need to revert to virtual dispatch.
>>
>> No it can't, and that is the problem. Even in the case of whole
> program analysis (and this often is practically not possible) you
> could have cases such is:
>
> void f(volatile bool b)
> {
> int* val = b ? new int(1): new(myallocator) int(2);
> ...
>
> // how to delete here?
> }
>
> /Peter
>
>
I did not say the knowledge will always be gained statically, I said it
*can* be gained statically. You provided an example where it certainly
can't. Might I also add that evil-looking code like this shouldn't be
written unless freeing through myallocator and through default free are
equivalent. And that *is* known when you call new.
Goran
> restor wrote:
> >> What's the rational for not having placement delete?
>
> > C++ has a placement delete it is just spelled differently: I believe
> > explicit destructor call. Consider an example:
>
> > void createAndDestroy( Class * obj )
> > {
> > new (obj) Class("obj1"); // ctor w/o allocation
> > obj->~Class(); // dtor w/o deallocation
> > }
>
> > I think the naming convention is confusing, as this question reoccurs
> > time and again. And it is the "placement new" that is confusing, as it
> > implies special (trivial) form of allocation. They probably should be
> > called "explicit constructor call" and "explicit destructor call".
>
> > Regards,
> > &rzej
>
> I believe you've misunderstood my point.
>
> I was talking about a general form of placement new, the one that takes
> any user-defined type, not just a pointer to void. You assumed that I
> was talking about a version of placement new that was taking a pointer
> to void. According to the standard it is not even possible to overload
> this function and yes, all it does is calls a constructor in the
> specified memory.
Ulrich also misunderstood you, I think, and that's because "placement
new" is not the best term, overloaded being better: your use isn't
"placement", and placement new is overloaded.
Goran.
Goran
> Goran Pusic wrote:
>
> >> That puts an unduly difficult requirement on (presumably custom)
> >> operator delete to figure out where the memory came from. And no, it's
> >> not always possible to embed that information with the returned memory.
>
> > Ahhh, but if you allocate instances of your class both from standard
> > heap and your own allocator, are these still the same class? If
> > nothing else, they are not the same WRT that particular detail that is
> > heap handling.
>
> Well, I don't want my types to be aware of actual physical memory
> placement. The same type can be allocated on the heap or anywhere else
> and that doesn't change the type's type.
Hmmm, yes, that's a noble theoretic goal ;-). But still, given that if
you could have two operators delete, you would have to keep track
which to call, it just doesn't buy you much (you do work that would be
done by the compiler if you did have two classes).
> > If that is the case, you could have variants of your class: base (with
> > actual functionality), one where you use default allocation and one
> > that comes from a pool. Then you pass reference to base around for
> > work, and call operator delete (compiler picks correct one for you)
> > when it's time to go.
>
> That would add virtual dispatch to classes that whouldn't need it
otherwise.
No, it wouldn't. operator delete ain't virtual, and it really is the
compiler that picks the "deletion" function. Did you mix operator
delete and the destructor in your mind?
itaj sherman
wrote:
> On 4 Dec., 19:56, Andy Venikov <swojchelo...@gmail.com> wrote:> Goran Pusic wrote:
>
> [snip]
> > > You should note that operator new and delete must "reverse-match" ;-)
> > > in functionality for a given class instance. Even if what you want to
> > > do was possible, you would still have to keep track of how a
> > > particular instance was instantiated so that you can call appropriate
> > > delete version. And if that is so, you could just as well split your
> > > instances in two actual classes and be done with it. In other words,
> > > it seems that you don't gain much (if anything) with your idea.
>
> > Hmmm, knowledge of what argument to use when calling delete can be
> > gained statically, without the need to revert to virtual dispatch.
>
> No it can't, and that is the problem. Even in the case of whole
> program analysis (and this often is practically not possible) you
> could have cases such is:
>
> void f(volatile bool b)
> {
> int* val = b ? new int(1): new(myallocator) int(2);
> ...
>
> // how to delete here?
//By Andy's hypothetical placement delete, like this:
b ? delete val : delete(myallocator) val;
>
> }
>
> /Peter
>
So what I think Andy seems to be asking, is whether there was a
specific reason not to include in c++ the option to overload operator
delete with parameters in symmetry with operator new, in such syntax.
That is, rather than not including it in c++, forcing us to use any of
the workarounds suggested here.
btw, I hope I didn't miss something important: what is the point in
'b' being volatile?
Seungbeom Kim
>
> btw, I hope I didn't miss something important: what is the point in
> 'b' being volatile?
My guess is that it is just meant to emphasize (to the human readers)
that you cannot determine the value of b statically, which would of
course hold even if volatile were not there.
I haven't seen volatile as a top-level qualifier (i.e. not through a
pointer or a reference), and I don't think it means anything significant.
Please correct me if I'm wrong.
--
Seungbeom Kim
Frank Birbacher
Seungbeom Kim schrieb:
> I haven't seen volatile as a top-level qualifier (i.e. not through a
> pointer or a reference), and I don't think it means anything significant.
> Please correct me if I'm wrong.
It means the value may change outside the program flow in this function.
void changeBool(volatile bool& what) {
what = true;
}
void doVolatile(volatile bool param) {
boost::thread(bind(&changeBool, ref(param)));
if(param)
...
}
I usually see volatile for global variables or class members.
Frank
--