Article View: comp.std.c++
Article #3831Re: Placement delete suggestion Keywords: delete placement
From: Fergus Henderson
Date: Wed, 27 Mar 1996 17:03
Date: Wed, 27 Mar 1996 17:03
72 lines
3708 bytes
3708 bytes
James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes: >b91926@fsgi01.fnal.gov (David Sachs) writes: > >|> The lack of a placement delete expression form, corresponding to >|> the placment new form, has been a topic for serious discussion in >|> this group. The obvious problem with placement delete is that >|> any non-awkward form could be ambiguous, though examples that >|> would show such ambguity are probably infrequent. > >|> In view of this, it might be reasonable if the standards committee >|> bit the bullet and declare that such ambiguous forms should be >|> treated as placement deletes. > >Is the expression: delete (*pf)( p ) placement delete or not? That would be placement delete. >(The variable pf has type `T* (*)( T* )', and p type T*.) Irrelevant, as far as syntax analysis goes -- syntax analysis is not concerned with the types of variables. Your code is however an example of the sort of code that would get broken by this proposal. >If not, why not? >If so, how can I remove the ambiguity (by adding parentheses or >otherwise)? You could remove the ambiguity by writing delete ((*pf)(p)); or simply delete pf(p); IMHO, David Sach's suggestion is a good one. Some of the committee members have tossed around this idea before, although I don't think it was ever formally proposed. The fact that it breaks existing code makes it a hard sell, and Bjarne was opposed to placement delete on the grounds that "at the point of deletion, the user can't be expected to know how the object was allocated" (D&E, section 10.5, page 214) and that consequently "the feature is feared to be error-prone" (ARM, section 5.3.4, page 66). The argument on the grounds of "protecting people against themselves" (D&E) doesn't really convince me, since as the ARM says, "added syntax isn't needed, since the problem can be solved without it". Rather than protecting them, you end up just forcing them to use an unintuitive syntax. The ARM continues: "The question is if such use is common enough to warrant the support of a special syntax.". I think the answer is yes, but at this stage I think it is probably too late to do anything about it. Not to worry -- it is a pretty minor syntax issue. Or is it? On second thoughts, I think the work-around suggested in the ARM of using a my_delete function won't work for array delete, since you don't know how many elements to delete. That is rather unfortunate -- it certainly limits the usefulness of placement array new. -- Fergus Henderson WWW: http://www.cs.mu.oz.au/~fjh fjh@cs.mu.oz.au PGP: finger fjh@128.250.37.3 --- [ comp.std.c++ is moderated. To submit articles: try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Technical Details
Message-ID:
<4jboij$4t3@mulga.cs.mu.OZ.AU>Path:
arc1-ca.pugleaf.net!in2.uu.net!bounce-backReferences:
<4j4ec5$d41@fsgi01.fnal.gov> <9603261124.AA22276@lts.sel.alcatel.de>Show Full Headers
Complete Article Headers
From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson) Message-ID: <4jboij$4t3@mulga.cs.mu.OZ.AU> X-Original-Date: 27 Mar 1996 15:58:11 GMT Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back Date: 27 Mar 96 17:03:40 GMT Approved: fjh@cs.mu.oz.au Newsgroups: comp.std.c++ Subject: Re: Placement delete suggestion Keywords: delete placement Organization: Comp Sci, University of Melbourne References: <4j4ec5$d41@fsgi01.fnal.gov> <9603261124.AA22276@lts.sel.alcatel.de> X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBMVl08uEDnX0m9pzZAQFogAF9HU3Izp3V4ztevaer+tZDMaHGOrXPydGp kBaTDlvsWWJ4Sb9b7X1JkxzWTIS8XSMF =exTH