kanze@gabi-soft.fr (J. Kanze) writes:

| smeyers@teleport.com (Scott Meyers) writes:
|
| |> But 5.3.5 also says this (my annotations are in square brackets):

The wording you quote is rather unclear, because it uses the phrase
"_the value of_ the operand of delete"; this would seem to indicate
that it refers to the value, not the type.  On the other hand, it
says that "the value of the operand of delete shall be ...  or ... or
an expression of class type".  This is inconsistent; a value cannot "be"
an expression.

Your interpretation may well be the intended one, but I think the
committee should clarify the wording of 5.3.5.

| |> As I hope my annotations show, the operand in a delete expression must
| |> be either a pointer (before conversions are applied) or a class object
| |> (before conversions are applied).  Hence I believe the code you posted
| |> should be rejected by compilers, though I don't know for sure whether
| |> they are required to diagnose the problem.  (I think the standard has
| |> to use magic words like "ill-formed" before a diagnostic is required.)
|
| If I understand you correctly, the following code is also illegal:
|
|    int*                a( (new int[ 10 ]) + 5 ) ;
|    //  a simulates an array with indexes in the range -5..4
|    delete [] (a - 5) ;
|
| Is this really the intent?

I don't see how you arrived at this conclusion from what Scott Meyers
said.  I don't see any evidence from the standard which would make the
above code ill-formed or cause it to have undefined behaviour.  I'm
also pretty sure that this wasn't the intent.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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                             ]

In article <4ou27q$n38@julie.teleport.com> smeyers@teleport.com (Scott
Meyers) writes:

|> But 5.3.5 also says this (my annotations are in square brackets):

|>   2 In  either  alternative [i.e., deletion of an object or deletion
|>     of an array], 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
|>     [case 1: the operand must be a pointer] to a non-array object created by
|>     a new-expression without a new-placement specification, or a pointer
|>     [case 2: the operand must be a pointer] to a sub-object (_intro.object_)
|>     representing a base class of such an object (_class.derived_), or an
|>     expression of class type [case 3: the operand must be an expression of
|>     class type] with a conversion function to pointer type
|>     (_class.conv,fct_) which yields a pointer to such an object [which is
|>     why the bug I posted about is explictly "supported"].  If not, the
|>     behavior is undefined.  In the second alternative (delete array), the
|>     value of the operand of delete shall be a pointer to an array created by
|>     a new-expression without a new- placement specification.  If not, the
|>     behavior is undefined.

|> As I hope my annotations show, the operand in a delete expression must
|> be either a pointer (before conversions are applied) or a class object
|> (before conversions are applied).  Hence I believe the code you posted
|> should be rejected by compilers, though I don't know for sure whether
|> they are required to diagnose the problem.  (I think the standard has
|> to use magic words like "ill-formed" before a diagnostic is required.)

If I understand you correctly, the following code is also illegal:

    int*                a( (new int[ 10 ]) + 5 ) ;
    //  a simulates an array with indexes in the range -5..4
    delete [] (a - 5) ;

Is this really the intent?
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


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