Article View: comp.std.c++
Article #3074Re: Why no allocator-specific delete?
From: David Sachs
Date: Tue, 23 Jan 1996 03:45
Date: Tue, 23 Jan 1996 03:45
70 lines
3386 bytes
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-backReferences:
<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