bop@gmb.dk ("Bo Persson") writes:

> "Alberto Barbati" <AlbertoBarbati@libero.it> skrev i meddelandet
> news:oKFrc.67150$Qc.2701321@twister1.libero.it...
>>
>> > Please pardon my ignorance, but *why* isn't explicit invocation of
> operator
>> > delete permitted? I got the space from a particular Arena (say), and
> I want
>> > to give it back - this seems a reasonable need. Why not?
>>
>> I really don't know. In fact I was surprised as you are when I first
>> discovered this. I guess that it would be too easy to mismatch a
>> placement new with its placement delete, but it doesn't seem to be a
>> very compelling argument.
>
> I think the reason is as simples as: There is no need for it!
>
> If you want to destroy the object pointed to by p, you just use the
> destructor for that object:
>
> p->~type();
>
> That destroys the object without deallocating any memory, alas a
> placement delete.

This is exactly the mental trap the language architects must have
    fallen into. It works fine so long as extra-argument new is solely
    placement new. Trouble comes when extra-argument new is something
    else.


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

do-not-spam-benh@bwsint.com (Ben Hutchings) writes:

> "Ivan Godard" wrote:
>> No no no! While they're called "placement new" and "placement dleete" for
>> historical reasons, new and delete with explicit arguments are also used to
>> tell which allocation regime (Arena, allocator etc.) the operator should
>> use. If for example I want to use std::malloc_allocator (say I'm going to
>> pass the result to a C function that is going to call "free" on it), I say
>> "new(std::malloc_allocator<int>) int". The qiuestion is why doesn't the
>> equivalent syntax exist for operator delete?
>
> The addition of "placement" syntax to new-expressions was backward-
> compatible because the optional parenthesised list of "placement"
> arguments can be distinguished from the type-id operand.
> Unfortunately the same sort of change to delete-expressions would not
> be backward-compatible because delete's operand is an expression
> rather than a type-id and might well be parenthesised.

AFAIK, a type-id in a new-expression can be parenthesised. This:

int main()
  {
    int* i= new (int);
  }

seems to be conforming.


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly wrote:
> do-not-spam-benh@bwsint.com (Ben Hutchings) writes:
>
>> "Ivan Godard" wrote:
>>> No no no! While they're called "placement new" and "placement dleete" for
>>> historical reasons, new and delete with explicit arguments are also used to
>>> tell which allocation regime (Arena, allocator etc.) the operator should
>>> use. If for example I want to use std::malloc_allocator (say I'm going to
>>> pass the result to a C function that is going to call "free" on it), I say
>>> "new(std::malloc_allocator<int>) int". The qiuestion is why doesn't the
>>> equivalent syntax exist for operator delete?
>>
>> The addition of "placement" syntax to new-expressions was backward-
>> compatible because the optional parenthesised list of "placement"
>> arguments can be distinguished from the type-id operand.
>> Unfortunately the same sort of change to delete-expressions would not
>> be backward-compatible because delete's operand is an expression
>> rather than a type-id and might well be parenthesised.
>
> AFAIK, a type-id in a new-expression can be parenthesised. This:
>
> int main()
>   {
>     int* i= new (int);
>   }
>
> seems to be conforming.

Yes, and that is because "(int)" can't be mistaken for a new-placement
since "int" isn't an expression.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

User-declared operator-delete is required to have a void* first argument,
plus any additional arguments (probably the allocator it cane from). If
instead the standard permitted:

class Arena{...};
template<typename T>
void operator delete(T* t, Arena& a) {...}

then the user function would have the size of a T available, which is likely
to be useful to a deallocator. Destructors are called before operator delete
as before, i.e. the argument t is uninitialized storage with the shape of a
T rather than a T object. The alternative is to create something like:

template<typename T>
void Delete(T* t, Arena& a) {...}

which is less transparent as to its function. The change is minor, breaks no
code, and make an old feature fit in with the newer parts of the language.
The same applies to operator delete[].

Ivan

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ivan Godard wrote:
> User-declared operator-delete is required to have a void* first argument,
> plus any additional arguments (probably the allocator it cane from).

Not really. A deallocation function that is going to be invoked by a
delete-expression must have either one of these signatures (12.5/5):

   void operator delete(void*);
   void operator delete(void*, size_t);

Deallocation functions with different signatures (a.k.a. placement
deallocation functions), such as

   void operator delete(void*, Arena&);

are used *only* in a very special case, that is when the program invokes
a corresponding placement allocation function to allocate memory for an
object but then object construction fails by throwing an exception
(5.3.4/17-19). You can't explicitly call a placement deallocation
function so its usefulness is very limited.

> then the user function would have the size of a T available, which is likely
> to be useful to a deallocator.

Please notice that if you use the two-parameter signature of a
(non-placement) deallocation function shown above, you will get the size
of the memory block as the second parameter. What more do you need?

Alberto

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

AlbertoBarbati@libero.it (Alberto Barbati) writes:
[snip]
> Deallocation functions with different signatures (a.k.a. placement
> deallocation functions), such as
>
>    void operator delete(void*, Arena&);
>
> are used *only* in a very special case, that is when the program
> invokes a corresponding placement allocation function to allocate
> memory for an object but then object construction fails by throwing an
> exception (5.3.4/17-19). You can't explicitly call a placement
> deallocation function so its usefulness is very limited.

But if you *need* to do extra-argument deallocation, it is necessary,
    but because extra-argument delete cannot be called explicitly, it
    is not allone sufficient; the user must implement a 'destroy()'
    function to replace extra-argument delete, which calls the
    destructor, and then a 'deallocate()' function, *in addition* to
    implementing  void operator delete(void*, Arena&); to also call
    the deallocate() function. The inability to explicitly call
    placement delete forces a user to first of all write extra code,
    and second write two functions which must behave identically, but
    one of which is only called in rare circumstances.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Alberto Barbati" <AlbertoBarbati@libero.it> wrote in message
news:R7brc.64734$Qc.2605853@twister1.libero.it...
> Ivan Godard wrote:
> > User-declared operator-delete is required to have a void* first
argument,
> > plus any additional arguments (probably the allocator it cane from).
>
> Not really. A deallocation function that is going to be invoked by a
> delete-expression must have either one of these signatures (12.5/5):
>
>    void operator delete(void*);
>    void operator delete(void*, size_t);

Is that so? Then gcc at least has this wrong: (from <new>, gcc3.4.0)

    // Default placement versions of operator delete.
    inline void  operator delete  (void*, void*) throw() { }
    inline void  operator delete[](void*, void*) throw() { }

Possibly the form with "size_t" is a proposal that is not yet part of the
standard?  Or is gcc just not yet current?

> Deallocation functions with different signatures (a.k.a. placement
> deallocation functions), such as
>
>    void operator delete(void*, Arena&);
>
> are used *only* in a very special case, that is when the program invokes
> a corresponding placement allocation function to allocate memory for an
> object but then object construction fails by throwing an exception
> (5.3.4/17-19). You can't explicitly call a placement deallocation
> function so its usefulness is very limited.

Here again whay you say may be true but doesn't jibe with (at least) current
gcc:
    #include <new>
     int* p;
     delete(p, p);
works fine.

Please pardon my ignorance, but *why* isn't explicit invocation of operator
delete permitted? I got the space from a particular Arena (say), and I want
to give it back - this seems a reasonable need. Why not?

> Please notice that if you use the two-parameter signature of a
> (non-placement) deallocation function shown above, you will get the size
> of the memory block as the second parameter. What more do you need?

When was this operator delete signature approved as a standard?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

AlbertoBarbati@libero.it (Alberto Barbati) wrote in message news:<R7brc.64734$Qc.2605853@twister1.libero.it>...
> Ivan Godard wrote:
> > User-declared operator-delete is required to have a void* first argument,
> > plus any additional arguments (probably the allocator it cane from).
>
> Not really. A deallocation function that is going to be invoked by a
> delete-expression must have either one of these signatures (12.5/5):
>
>    void operator delete(void*);
>    void operator delete(void*, size_t);
[...]
> Please notice that if you use the two-parameter signature of a
> (non-placement) deallocation function shown above, you will get the size
> of the memory block as the second parameter. What more do you need?

This only applies to class-scope allocation functions.  You cannot
replace the global operator delete with one that takes the a size_t.

--
Richard Smith

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 21 May 2004 16:34:56 +0000 (UTC), igodardA@TpacbellDO.Tnet
("Ivan Godard") wrote:

>Here again whay you say may be true but doesn't jibe with (at least) current
>gcc:
>    #include <new>
>     int* p;
>     delete(p, p);
>works fine.

It just calls the normal operator delete though. delete is an
operator, not a function. (p, p) is just an expression using the comma
operator, and evalutates to the second subexpression, p.

>Please pardon my ignorance, but *why* isn't explicit invocation of operator
>delete permitted? I got the space from a particular Arena (say), and I want
>to give it back - this seems a reasonable need. Why not?

Indeed, I've wondered myself. The rules make overloading of placement
new less useful than it might be.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 21 May 2004 16:34:56 +0000 (UTC), igodardA@TpacbellDO.Tnet
("Ivan Godard") wrote:

> "Alberto Barbati" <AlbertoBarbati@libero.it> wrote in message
> news:R7brc.64734$Qc.2605853@twister1.libero.it...
> > Ivan Godard wrote:
> > > User-declared operator-delete is required to have a void* first
> argument,
> > > plus any additional arguments (probably the allocator it cane from).

> > Not really. A deallocation function that is going to be invoked by a
> > delete-expression must have either one of these signatures (12.5/5):

Note the importance of "going to be invoked by a delete-expression".

> >    void operator delete(void*);
> >    void operator delete(void*, size_t);

> Is that so? Then gcc at least has this wrong: (from <new>, gcc3.4.0)

>     // Default placement versions of operator delete.
>     inline void  operator delete  (void*, void*) throw() { }
>     inline void  operator delete[](void*, void*) throw() { }

These are placement delete functions which will never be invoked by a
delete-expression.

> Here again whay you say may be true but doesn't jibe with (at least) current
> gcc:

>     #include <new>
>      int* p;
>      delete(p, p);
> works fine.

Depends upon what you mean by works.  There is a difference between a
delete-expression and an operator delete function.  The above is a
delete-expression which is the delete key word followed by an
expression.  The expression is (p, p) where that is the comma operator.
You may as well write delete(42, p).  It generates the same code.  For
real fun, try delete "The world of C++ is a mess", p;  It also "works
fine".  None of them invoke the placement delete function.  They all
invoke the normal operator delete.

> Please pardon my ignorance, but *why* isn't explicit invocation of operator
> delete permitted? I got the space from a particular Arena (say), and I want
> to give it back - this seems a reasonable need. Why not?

Actually it is allowed.  operator delete(p, p);  It is not possible to
use a delete expression to implicetly invoke it.  The name of the
function is operator delete and its full name must be used to call it.

There seems to be the usual confusion between the delete-expression and
the operator delete function.  Two very different things.

John

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ivan Godard wrote:
> "Alberto Barbati" <AlbertoBarbati@libero.it> wrote in message
> news:R7brc.64734$Qc.2605853@twister1.libero.it...
>>
>>Not really. A deallocation function that is going to be invoked by a
>>delete-expression must have either one of these signatures (12.5/5):
>>
>>   void operator delete(void*);
>>   void operator delete(void*, size_t);
>
> Is that so? Then gcc at least has this wrong: (from <new>, gcc3.4.0)
>
>     // Default placement versions of operator delete.
>     inline void  operator delete  (void*, void*) throw() { }
>     inline void  operator delete[](void*, void*) throw() { }

As the comment clearly states, these are "placement versions of operator
delete". Placement versions are never "invoked by a delete-expression"
as correctly remarked by John Potter.

> Possibly the form with "size_t" is a proposal that is not yet part of the
> standard?  Or is gcc just not yet current?

The form with size_t has been part of the standard since 1998. What I
forgot to say (thanks to Richard Smith for having pointed this out) is
that the choice between delete(void*) and delete(void*, size_t) is only
for class-scope deallocation functions. The choice is exclusive, if both
functions are declared, then delete(void*) is used for
delete-expressions and delete(void*, size_t) is considered to be a
placement version. At global scope, there is always a delete(void*), so
delete(void*, size_t) is always a placement version.

> Here again whay you say may be true but doesn't jibe with (at least) current
> gcc:
>     #include <new>
>      int* p;
>      delete(p, p);
> works fine.

As said by others, this syntax invokes operator,() that discards the
first p, so it is essentially identical to delete(p).

> Please pardon my ignorance, but *why* isn't explicit invocation of operator
> delete permitted? I got the space from a particular Arena (say), and I want
> to give it back - this seems a reasonable need. Why not?

I really don't know. In fact I was surprised as you are when I first
discovered this. I guess that it would be too easy to mismatch a
placement new with its placement delete, but it doesn't seem to be a
very compelling argument.

If you need such a memory management with current C++, you have two
ways: either you have placement-new store a reference to the arena in
the memory block itself (so that delete will know the correct arena
without having it passed as a parameter) or avoid delete-expressions
entirely (invoke the destructor explicitly and then deallocate memory,
just as all standard container do via allocators).

>>Please notice that if you use the two-parameter signature of a
>>(non-placement) deallocation function shown above, you will get the size
>>of the memory block as the second parameter. What more do you need?
>
> When was this operator delete signature approved as a standard?

In 1998.

Alberto

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Update on situation in gcc3.4.0:
<new> declares:
    // Default placement versions of operator delete.
    inline void  operator delete  (void*, void*) throw() { }
    inline void  operator delete[](void*, void*) throw() { }
A test of these declarations:
    int main() {
        void* pi;void* pj;
        pi delete pj;
        return 0;
        }
(note - my prior effort confused *function* delete with *operator* delete -
duh!) produces:
    foo.cc: In function `int main()':
    foo.cc:4: error: expected `;' before "delete"

So dyadic delete in fact *doesn't* work in G++, despite the declaration.

That still leaves the question: what's wrong with a placement (i.e. dyadic)
operator delete? Why does the standard prohibit e.g.:
    arena delete foo;
And to go back to my original question, why not also let operator delete be
templated on the types of the arguments, so that
size info is available without requiring it as an explicit size_t argument,
as one poster here asserts is now standard?

Ivan

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Well I sure admit I'm confused:

I understand that "delete foo;" and "delete (anything, foo);" invoke the
same thing because of the comma-operator; my bad. But then the syntax for a
dyadic (placement) operator delete invocation should be "anything delete
foo", calling "void operator delete(T1, T2)" by analogy with "a+b" calling
"T3 operator+(T1, T2)". The dyadic syntax might look a little odd, but the
present monadic syntax is really an operator trying to pretend to be a
keyword-statement, and if it really is an operator then that's what you can
do with operators. Yes, I understand that "p->operator delete(x,y)" exists
too, but that's not what I'm trying to overload.

Dyadic use of global delete would be useful (so you can use the existing
mechanism for arena-like or placement-like allocation/deallocation); it fits
with the language; in my ignorance I don't *see* any ambiguity; it naturally
extends to templates and type-based polymorphic allocation/deallocation. Why
not? And if the answer is "no good reason", where does one make the
proposal?

Ivan

"John Potter" <jpotter@falcon.lhup.edu> wrote in message
news:4Mqrc.17382$zO3.15568@newsread2.news.atl.earthlink.net...
> On Fri, 21 May 2004 16:34:56 +0000 (UTC), igodardA@TpacbellDO.Tnet
> ("Ivan Godard") wrote:
>
> > "Alberto Barbati" <AlbertoBarbati@libero.it> wrote in message
> > news:R7brc.64734$Qc.2605853@twister1.libero.it...
> > > Ivan Godard wrote:
> > > > User-declared operator-delete is required to have a void* first
> > argument,
> > > > plus any additional arguments (probably the allocator it cane from).
>
> > > Not really. A deallocation function that is going to be invoked by a
> > > delete-expression must have either one of these signatures (12.5/5):
>
> Note the importance of "going to be invoked by a delete-expression".
>
> > >    void operator delete(void*);
> > >    void operator delete(void*, size_t);
>
> > Is that so? Then gcc at least has this wrong: (from <new>, gcc3.4.0)
>
> >     // Default placement versions of operator delete.
> >     inline void  operator delete  (void*, void*) throw() { }
> >     inline void  operator delete[](void*, void*) throw() { }
>
> These are placement delete functions which will never be invoked by a
> delete-expression.
>
> > Here again whay you say may be true but doesn't jibe with (at least)
current
> > gcc:
>
> >     #include <new>
> >      int* p;
> >      delete(p, p);
> > works fine.
>
> Depends upon what you mean by works.  There is a difference between a
> delete-expression and an operator delete function.  The above is a
> delete-expression which is the delete key word followed by an
> expression.  The expression is (p, p) where that is the comma operator.
> You may as well write delete(42, p).  It generates the same code.  For
> real fun, try delete "The world of C++ is a mess", p;  It also "works
> fine".  None of them invoke the placement delete function.  They all
> invoke the normal operator delete.
>
> > Please pardon my ignorance, but *why* isn't explicit invocation of
operator
> > delete permitted? I got the space from a particular Arena (say), and I
want
> > to give it back - this seems a reasonable need. Why not?
>
> Actually it is allowed.  operator delete(p, p);  It is not possible to
> use a delete expression to implicetly invoke it.  The name of the
> function is operator delete and its full name must be used to call it.
>
> There seems to be the usual confusion between the delete-expression and
> the operator delete function.  Two very different things.
>
> John
>
> ---
> [ 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    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Alberto Barbati" <AlbertoBarbati@libero.it> skrev i meddelandet
news:oKFrc.67150$Qc.2701321@twister1.libero.it...
>
> > Please pardon my ignorance, but *why* isn't explicit invocation of
operator
> > delete permitted? I got the space from a particular Arena (say), and
I want
> > to give it back - this seems a reasonable need. Why not?
>
> I really don't know. In fact I was surprised as you are when I first
> discovered this. I guess that it would be too easy to mismatch a
> placement new with its placement delete, but it doesn't seem to be a
> very compelling argument.

I think the reason is as simples as: There is no need for it!

If you want to destroy the object pointed to by p, you just use the
destructor for that object:

p->~type();

That destroys the object without deallocating any memory, alas a
placement delete.


Bo Persson


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

No no no! While they're called "placement new" and "placement dleete" for
historical reasons, new and delete with explicit arguments are also used to
tell which allocation regime (Arena, allocator etc.) the operator should
use. If for example I want to use std::malloc_allocator (say I'm going to
pass the result to a C function that is going to call "free" on it), I say
"new(std::malloc_allocator<int>) int". The qiuestion is why doesn't the
equivalent syntax exist for operator delete?

Ivan

""Bo Persson"" <bop@gmb.dk> wrote in message
news:2hbd0nFb3lplU1@uni-berlin.de...
>
> "Alberto Barbati" <AlbertoBarbati@libero.it> skrev i meddelandet
> news:oKFrc.67150$Qc.2701321@twister1.libero.it...
> >
> > > Please pardon my ignorance, but *why* isn't explicit invocation of
> operator
> > > delete permitted? I got the space from a particular Arena (say), and
> I want
> > > to give it back - this seems a reasonable need. Why not?
> >
> > I really don't know. In fact I was surprised as you are when I first
> > discovered this. I guess that it would be too easy to mismatch a
> > placement new with its placement delete, but it doesn't seem to be a
> > very compelling argument.
>
> I think the reason is as simples as: There is no need for it!
>
> If you want to destroy the object pointed to by p, you just use the
> destructor for that object:
>
> p->~type();
>
> That destroys the object without deallocating any memory, alas a
> placement delete.
>
>
> Bo Persson
>
>
> ---
> [ 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    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ivan Godard" wrote:
> No no no! While they're called "placement new" and "placement dleete" for
> historical reasons, new and delete with explicit arguments are also used to
> tell which allocation regime (Arena, allocator etc.) the operator should
> use. If for example I want to use std::malloc_allocator (say I'm going to
> pass the result to a C function that is going to call "free" on it), I say
> "new(std::malloc_allocator<int>) int". The qiuestion is why doesn't the
> equivalent syntax exist for operator delete?

The addition of "placement" syntax to new-expressions was backward-
compatible because the optional parenthesised list of "placement"
arguments can be distinguished from the type-id operand.
Unfortunately the same sort of change to delete-expressions would not
be backward-compatible because delete's operand is an expression
rather than a type-id and might well be parenthesised.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]