🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #3074

Re: Why no allocator-specific delete?

#3074
From: David Sachs
Date: Tue, 23 Jan 1996 03:45
70 lines
3386 bytes
clamage@Eng.Sun.COM (Steve Clamage) writes:

>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.

>No good syntax was found for such. The obvious syntax
>	delete (x) p;
>leads to too many ambiguities. More importantly, it means that the
>point of deletion would somehow have to know what placement version
>of "new" was used and what the parameters were. Needing that knowledge
>would make "placement delete" unsafe and hard to use. (Consider the
>general case where the "new" and "delete" expressions are in different
>compilation units, and the parameters to "new" affect how "delete"
>should be called.)

>You can define a version of "operator delete()" corresponding to a
>placement new. If the constructor for the object exits via an exception,
>the compiler will call the corresponding placement delete automatically
>as a special case.
>	T* p = new (x) T;
>The reasons for this special case are
>1. You do not know what needs to be deleted in general, but the compiler
>does.
>2. The compiler has all the information it needs to invoke the special
>operator delete() correctly. It is invoked at the point of the
>new-expression.

>>but there is no matching version of 'delete'? Are we supposed to use both 
>>destroy() and deallocate() to get rid of that object?

>Yes. In the above example:
>	p->~T();
>	operator delete(p, x);

How can you guarantee that the first argument to operator delete
will be correct? It might be slightly safer to write:

	void* q = p;  // evaluate before destruction
	p->~T();
	operator delete(q,x);

and I am not sure if this is guaranteed to be safe.

One form for placement operator delete, that might avoid ambiguity is:

delete (placement parameters) (pointer)

The extra parentheses around the pointer would make this not a
syntactically correct non-placement delete.
-- 
* IRS, IRS, lord of the federal tax, checking all income and every deduction,*
* mailing out form 10 40, penalizing noncompliers, regulating, and auditing. *
David Sachs - Fermilab, HPPC MS369 - P. O. Box 500 - Batavia, IL 60510
Voice: 1 708 840 3942      Deparment Fax: 1 708 840 3785
---
[ 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. ]
Technical Details
Message-ID: <4e1jfb$1ea@fsgm01.fnal.gov>
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
References: <4dvid8$460@news.bridge.net> <4e0u1s$5fv@engnews1.Eng.Sun.COM>

Show Full Headers
Complete Article Headers
From: b91926@fsgm01.fnal.gov (David Sachs)
Message-ID: <4e1jfb$1ea@fsgm01.fnal.gov>
X-Original-Date: 22 Jan 1996 21:08:27 -0600
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
Date: 23 Jan 96 03:45:36 GMT
Approved: fjh@cs.mu.oz.au
Newsgroups: comp.std.c++
Subject: Re: Why no allocator-specific delete?
Organization: FERMILAB, Batavia, IL
References: <4dvid8$460@news.bridge.net> <4e0u1s$5fv@engnews1.Eng.Sun.COM>
Reply-To: sachs@fnal.fnal.gov
X-Newsreader: NN version 6.5.0 #4 (NOV)
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBFAgUBMQRaKOEDnX0m9pzZAQHUQQF/dgjskvnZKgm7/fdCYwEy3SwFjWn+fK13
 5GfZNI6NLHucwvj6C8GC8iQKVWKBkYPB
 =dy+z