Is the following code legal?

> struct MyType { } mytype;
>
> void* operator new(size_t size, MyType)
> {
> return ::operator new(size);
> }
>
> struct MyClass { int a; /* other members omitted */ } ;
>
> main()
> {
> MyClass *mcp = new(mytype) MyClass;
>
> delete mcp;
> }

In other words, is it OK to use the delete operator on memory which was
obtained from operator new, but indirectly?

The following passage from the DWP [expr.delete] suggests not, but I
cannot see a good reason for the restriction.

> In either alternative, if the value of the operand of  delete  is  the
> null  pointer  the  operation  has no effect.  Otherwise, in the first
> alternative (delete object), the value of the operand of delete  shall
> be a pointer to a non-array object created by a new-expression without
> a  new-placement  specification,  or  a  pointer   to   a   sub-object
> (_intro.object_)   representing   a  base  class  of  such  an  object
> (_class.derived_), or an expression of class type  with  a  conversion
> function  to pointer type (_class.conv.fct_) which yields a pointer to
> such an object.  If not, the behavior is  undefined.

Thanks in advance for any insights!


--
Misha Dorman                             email: mishad@iplbath.com
Software Products Group                  WWW:   http://www.iplbath.com
IPL Information Processing Ltd           Tel:   +44 (0)1225 444888
Eveleigh House, Grove Street, Bath BA1 5LR, England
---
[ 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 <844420834.23354.0@worf.iplbath.com> Misha Dorman
<mishad@iplbath.com> writes:

|> Is the following code legal?

|> > struct MyType { } mytype;
|> >
|> > void* operator new(size_t size, MyType)
|> > {
|> > return ::operator new(size);
|> > }
|> >
|> > struct MyClass { int a; /* other members omitted */ } ;
|> >
|> > main()
|> > {
|> > MyClass *mcp = new(mytype) MyClass;
|> >
|> > delete mcp;
|> > }

|> In other words, is it OK to use the delete operator on memory which was
|> obtained from operator new, but indirectly?

IMHO, yes, albeit only implicitly.

|> The following passage from the DWP [expr.delete] suggests not, but I
|> cannot see a good reason for the restriction.

|> > In either alternative, if the value of the operand of  delete  is  the
|> > null  pointer  the  operation  has no effect.  Otherwise, in the first
|> > alternative (delete object), the value of the operand of delete  shall
|> > be a pointer to a non-array object created by a new-expression without
|> > a  new-placement  specification,  or  a  pointer   to   a   sub-object
|> > (_intro.object_)   representing   a  base  class  of  such  an  object
|> > (_class.derived_), or an expression of class type  with  a  conversion
|> > function  to pointer type (_class.conv.fct_) which yields a pointer to
|> > such an object.  If not, the behavior is  undefined.

|> Thanks in advance for any insights!

I see your point.  I think that the problem is only one of wording;
other places in the standard:

1. Define the exact operations which occur in a new expression, i.e.:
call of an "operator new" function, followed by the constructor.

2. Define the exact operations which occur in a delete expression, i.e.:
call of the destructor, followed by the "operator delete" function.

3. Define the relationship between the operator new and operator delete
*functions*.  IMHO, in the above scenario, operator delete is given a
pointer (type void*) which was returned by operator new, so the results
are (or should be) defined.

Despite the words which you quote, I do not think it possible for an
implementation to meet all of the required criteria and not work in the
case you cite.

I can understand the committee wanting to make arbitrary use undefined;
my knowledge of standardese is not great enough to know whether the
other requirements override the "undefined" here or not.  (If they do, a
footnote or comment to this effect would be nice, especially in the
absense of a rationale.)

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