🚀 go-pugleaf

In article <4e85k6$b04@noc.tor.hookup.net> mtimmerm@microstar.com
(Matt Timmermans) writes:

|> (clamage@Eng.Sun.COM (Steve Clamage))

|> |   In article 460@news.bridge.net, David Byrden
|> |   <100101.2547@compuserve.com> writes:
|> |   >Why, in the Septenber draft standard, is an allocator-specific verrion
|> |   >of 'new' provided;
|> |   >
|> |   >20.1.4.4
|> |   >
|> |   >           new(x) T    
|> |   >
|> |   >    returns an X::types<T>::pointer, where x is of an 
|> |   >    allocator type X

|> |   You are actually referring to the "placement new" syntax not having a
|> |   corresponding "placement delete" syntax.

|> Yes, and this is very annoying.  The lack of a placement-delete makes
|> placement-new nearly useless.  I can't, in fact, think of a single way that
|> placement-new could be used properly.

The most common usage of placement new is simply to invoke the
constructor on an arbitrary block of memory.  Since the destructor can
be invoked directly, there is no need for a corresponding placement
delete.

Another potential use of placement new is that described in the
standard: adding a parameter to modify error handling.

Finally, if you really are using the placement to pass information
concerning which arena to use, presumably each arena has a distinct
address range, so you can overload operator delete to test the address
range and choose the correct arena.  In this case, it is a bit of a
bother that you can no longer get at the original operator delete, so
you have to overload the normal operator new too.  (Luckily malloc is
still available.)

|> The lack of a placement-delete is on of the many factors in C++ conspiring
|> to make it absolutely impossible to make generic collections that hold
|> actual objects (with constructors) instead of just pointers.

I don't understand the problem.  My containers all contain actual
objects, and not just pointers.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]