🚀 go-pugleaf

In article <smeyersDD2y1C.9nn@netcom.com>, smeyers@netcom.com (Scott
Meyers) wrote:

> Is the following correct?
> 
>   - Non-class operator delete can take any number and types of
>     arguments as long as the first argument is of type void*.

Yes.

>   - There may be at most two operator delete functions declared in a
>     class, and they must have these signatures:
>     
>       void X::operator delete(void*);
>       void X::operator delete(void*, size_t);

No.  There may be any number of delete functions in a class.  If present,
the first form above is always the usual delete.  Any which matches neither
of these forms is a placemeent delete.  If the second form appears, it's
the usual delete if the first form is missing; else it's a placement delete.
This is obviously more complex than one would like, but it's the simplest
scheme which does not require new syntax or keywords.

The wording about not overloading delete is obsolete.  When the "delete"
keyword is used, only the non-placement delete (and there is only one of
these) is ever called.  But when operator delete is invoked explicitly,
it is just an ordinary function and of course overloading rules apply.
  
> Finally, why is the obvious syntax for "placement delete" not allowed?
> The committee must surely have considered and rejected it.  That is,
> why is this not legal for the example above that started this thread?
> 
>   delete (&allocator) p;

But what about:

    delete (&allocator) * p;

This is syntactically ambiguous (and it can be made semantically
ambiguous if "p" is an object of a class with both unary and binary
overloaded operator*).

A similar situation occurs with new-expressions:

    new int * * x;

The resolution for types is to use as many tokens as possible in the type.

But the situation with types (for "new") is fairly simple, since the
only ambiguities involve trailing "*" and "&".  The corresponding
situation with expressions is a little more complex, and the committee
did not consider it worth the added complexity, not to mention the
potential for breaking existing code.  Of course you're free to disagree.

-- 
Bill Gibbons
bgibbons@taligent.com