🚀 go-pugleaf

In article d41@fsgi01.fnal.gov, 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. 

The subject was discussed at some length in the C++ committee. The
bullet has been thoroughly chewed and is now quite unappetizing. So far
as I know, the committee has no interest in revisiting the decision.
The short answer is that a thorough analysis showed such a facility
would have too many problems and too little utility.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

In article <4j4ec5$d41@fsgi01.fnal.gov> 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. That should be anything of the form:

|> delete leftparenthesis expressionlist rightparenthesis expression

|> delete[] leftparenthesis expressionlist rightparenthesis expression

|> Admitedly, this would probably break some existing code, but the
|> broken expressions can be fixed by adding parentheses.

Is the expression: delete (*pf)( p ) placement delete or not?  (The
variable pf has type `T* (*)( T* )', and p type T*.)  If not, why not?
If so, how can I remove the ambiguity (by adding parentheses or
otherwise)?

--
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, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone



[ 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                             ]

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                             ]

James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
...

>Is the expression: delete (*pf)( p ) placement delete or not?  (The
>variable pf has type `T* (*)( T* )', and p type T*.)  If not, why not?
>If so, how can I remove the ambiguity (by adding parentheses or
>otherwise)?
If my idea were adapted, the example you gave would be treated as a
placement delete. It could be disambiguated by adding a pair of
parentheses to make it:

delete ((*pf)( p ))

In extremely complex cases you might even need

(delete ((*pf)( p )))
-- 
***** Listen Americans, the IRS is your taxer,  the IRS is one. *****
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.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

Hi,
Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
: 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.

OTOH, as Tim Hollebeek observed in a thread in comp.lang.c++.moderated
(Placement new and arrays), the usefulness of placement array new is
limited anyway: There is no portable way to figure out how much
"allocation overhead" there will be and thus it is impossible to
predict how much memory has to be set aside for a placement array new.
In fact, it turns out that it is impossible to place an array at a
specific address with placement new due to this allocation overhead:
See the example in expr.new verse 12 of the April DWP: "... - 'new(2,f)
T[5]' results in a call of 'operator new[](sizeof(T)*5+y,2,f)'. Here,
'x' and 'y' are non-negative, implementation-defined values
represeneting array allocation overhead. They migh vary from one use of
'new' to another.". There is nothing said about the address of the
first element of the array... The only portable way I know to place an
array at a specific address in a chunk of memory whose size can be
predicted, is to do it "by hand", i.e. using placement (non-array) new
for each individual element of the array (and, of course, using
explicit destructor calls to release the objects).
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

Dietmar Kuehl (kuehl@uzwil.informatik.uni-konstanz.de) wrote:

> OTOH, as Tim Hollebeek observed in a thread in comp.lang.c++.moderated
> (Placement new and arrays), the usefulness of placement array new is
> limited anyway: There is no portable way to figure out how much
> "allocation overhead" there will be and thus it is impossible to
> predict how much memory has to be set aside for a placement array new.

But there is a way to way to figure out how much is "allocation overhead"!
Here an example:

void* operator new[](size_t size, size_t& retSize) {
   retSize = size;
   return NULL;
}

So you can call write something like this:

class T { ... };
...
size_t size;
new(size) T[100];
T* p = new(alloca(size)) T[100]; // allocate memory from stack
...
for (int i = 99; i >= 0; i--) { p[i].~T(); } 
  // instead of placement delete ...

--
With best regards, Igor Boukanov 
igor.boukanov@fi.uib.no  http://www.fi.uib.no/~boukanov
---
[ 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                             ]