From: Ulrich Eckhardt on
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.

> 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


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Francis Glassborow on
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.
>
> 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.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Stuart Golodetz on
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.
>
> 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

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Hyman Rosen on
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);

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andy Venikov on
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.

Thanks,
Andy.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]