🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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

Re: Placement delete suggestion Keywords: delete placement

#3831
From: Fergus Henderson
Date: Wed, 27 Mar 1996 17:03
72 lines
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-back
References: <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