Matthias Hofmann wrote:
>>Consider the code:
>>
>>int* a = 0;
>>delete a;
>>
>>then the cast-expression is "a" while its value is the null pointer
>>value (of type int*).
>
> I do not see any cast-expression here.

It's "a". In fact "a" is a primary-expression (5.1), but any
primary-expression is also a postfix-expression (5.2), any
postfix-expression is also a unary-expression (5.3) and finally any
unary-expression is also a cast-expression (5.4).

> The standard does define precisely what happens when a user defined operator
> delete is called:
>
> 3.7.3/3 "Any allocation or deallocation functions defined in a C++ program
> shall conform to the semantics defined in 3.7.3.1 and 3.7.3.2"

You got the point, here.

Cheers,

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                       ]

hofmann@anvil-soft.com ("Matthias Hofmann") wrote in message news:<bqnn97$2d1$3@news1.nefonline.de>...
> Alberto Barbati <AlbertoBarbati@libero.it> schrieb in im Newsbeitrag:
> 1Ltzb.161734$vO5.6346206@twister1.libero.it...
> > Matthias Hofmann wrote:
> > > To be honest, I don't see a big difference between "the cast-expression"
>  and
> > > "the value of the cast-expression".
> >
> > Consider the code:
> >
> > int* a = 0;
> > delete a;
> >
> > then the cast-expression is "a" while its value is the null pointer
> > value (of type int*).
>
> I do not see any cast-expression here.

5.4p2:
_cast-expression_:
        _unary-expression_

5.3p1:
_unary-expression_:
        _postfix-expression_

5.2p1:
_postfix-expression_:
        _primary-expression_

5.1p1:
_primary-expression_:
        _id-expression_

_id-expression_:
        _unqualified-id_

_unqualified-id_:
        _identifier_

2.10p1:
_identifier_:
        _nondigit_

_nondigit_
        a

"a" is therefore a non-digit, an identifier, an unqualified-id, an
id-expression, a primary-expression, a postfix-expression, a
unary-expression, and a cast-expression. Since the thing that's
supposed to follow 'delete' is a cast-expression, this is the correct
way to parse "a".

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

Hello!

After some discussion in comp.lang.c++.moderated we came to the conclusion
that there seems to be a defect in 5.3.5/4, which says:

"The cast-expression in a delete-expression shall be evaluated exactly once.
If the delete-expression calls the implementation deallocation function
(3.7.3.2), and if the operand of the delete expression is not the null
pointer constant, the deallocation function will deallocate the storage
referenced by the pointer thus rendering the pointer invalid. [Note: the
value of a pointer that refers to deallocated storage is indeterminate. ]"

In the second sentence, the term "null pointer constant" should be changed
to "null pointer". In its present form, the passage claims that the
deallocation function will deallocate the storage refered to by a null
pointer that did not come from a null pointer constant in the delete
expression. Besides, how can the null pointer constant be the operand of a
delete expression, as "delete 0" is an error because delete requires a
pointer type or a class type having a single conversion function to a
pointer type?

Regards,

Matthias Hofmann

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

Matthias Hofmann wrote:
> Hello!
>
> After some discussion in comp.lang.c++.moderated we came to the conclusion
> that there seems to be a defect in 5.3.5/4, which says:
>
> "The cast-expression in a delete-expression shall be evaluated exactly once.
> If the delete-expression calls the implementation deallocation function
> (3.7.3.2), and if the operand of the delete expression is not the null
> pointer constant, the deallocation function will deallocate the storage
> referenced by the pointer thus rendering the pointer invalid. [Note: the
> value of a pointer that refers to deallocated storage is indeterminate. ]"
>
> In the second sentence, the term "null pointer constant" should be changed
> to "null pointer". <snips>

IMHO, this wording does not completely solve the issue. The problematic
word here is "operand" that can be interpreted as either "the
cast-expression" or "the value of the cast-expression".

I suggest replacing the words "if the operand of the delete-expression
is not the null pointer constant" with "if the cast-expression evaluates
to a non-null pointer".

How does it sound?

Alberto Barbati

---
[ 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> schrieb in im Newsbeitrag:
VP5zb.163486$e6.5981527@twister2.libero.it...
> Matthias Hofmann wrote:
> > Hello!
> >
> > After some discussion in comp.lang.c++.moderated we came to the
conclusion
> > that there seems to be a defect in 5.3.5/4, which says:
> >
> > "The cast-expression in a delete-expression shall be evaluated exactly
once.
> > If the delete-expression calls the implementation deallocation function
> > (3.7.3.2), and if the operand of the delete expression is not the null
> > pointer constant, the deallocation function will deallocate the storage
> > referenced by the pointer thus rendering the pointer invalid. [Note: the
> > value of a pointer that refers to deallocated storage is
indeterminate. ]"
> >
> > In the second sentence, the term "null pointer constant" should be
changed
> > to "null pointer". <snips>
>
> IMHO, this wording does not completely solve the issue. The problematic
> word here is "operand" that can be interpreted as either "the
> cast-expression" or "the value of the cast-expression".
>
> I suggest replacing the words "if the operand of the delete-expression
> is not the null pointer constant" with "if the cast-expression evaluates
> to a non-null pointer".
>
> How does it sound?
>

To be honest, I don't see a big difference between "the cast-expression" and
"the value of the cast-expression".

I wasn't sure wether the entire passage was merely about casting. It seems
as we have to find a phrase that expresses the idea of the null pointer
constant being casted to a pointer to whatever, and this is this whole thing
(the cast expression) is the operand of delete, like so:

delete static_cast<char*>( 0 );

or

delete (void*) 0;

One more thing: The passage says "If the delete-expression calls the
implementation deallocation function" - why does it only talk about the
implementation deallocation function, and how come the sentence starts with
an "if"? Is there any reason not to call the deallocation function, and what
about my own version of operator delete()?

Regards,

Matthias



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

Matthias Hofmann wrote:
> To be honest, I don't see a big difference between "the cast-expression" and
> "the value of the cast-expression".

Consider the code:

int* a = 0;
delete a;

then the cast-expression is "a" while its value is the null pointer
value (of type int*).

However, I acknowledge that the meaning of the word "operand" in this
context has been clearly specified in paragraph 2 (it's the value), so
my objection is not really relevant.

That said I reconsider my proposal, your suggestion to simply replace
"null pointer constant" with "null pointer" looks now perfectly
reasonable to me.

By the way, also in paragraph 2 it's said that "if the value of the
operand of delete is the null pointer the operation has no effect." So
it seems to me a bit redundant to specify in paragraph 4 that a
behaviour (deallocating the storage) occurs only if the operand is not a
null pointer. Doh! Repetita juvant.

> I wasn't sure wether the entire passage was merely about casting. It seems
> as we have to find a phrase that expresses the idea of the null pointer
> constant being casted to a pointer to whatever, and this is this whole thing
> (the cast expression) is the operand of delete, like so:
>
> delete static_cast<char*>( 0 );
>
> or
>
> delete (void*) 0;

I don't think this paragraph has anything to do with casting. A
cast-expression is defined in 5.4 as

   cast-expression:
     unary-expression
     ( typeid ) cast-expression

so it may not include any kind of cast. What is important is just the
value of the expression.

> One more thing: The passage says "If the delete-expression calls the
> implementation deallocation function" - why does it only talk about the
> implementation deallocation function, and how come the sentence starts with
> an "if"? Is there any reason not to call the deallocation function, and what
> about my own version of operator delete()?

The implementation deallocation function is, obviously, not called if a
user-provided version of operator delete is chosen instead.

I interpret the statement above as just a specification of the behaviour
of the implementation deallocation function. If the implementation
deallocation function is called and the operand is non-null, the storage
will be deallocated (imperative!). If it's not called, i.e. a
user-defined operator delete is called in its place, the standard
doesn't specify what happens because it can't: the storage may be
deallocated or not, it's all up to the user who provided the replacement
function.

Regards,

Alberto Barbati

---
[ 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> schrieb in im Newsbeitrag:
1Ltzb.161734$vO5.6346206@twister1.libero.it...
> Matthias Hofmann wrote:
> > To be honest, I don't see a big difference between "the cast-expression"
and
> > "the value of the cast-expression".
>
> Consider the code:
>
> int* a = 0;
> delete a;
>
> then the cast-expression is "a" while its value is the null pointer
> value (of type int*).

I do not see any cast-expression here.

[snip]

>
> > One more thing: The passage says "If the delete-expression calls the
> > implementation deallocation function" - why does it only talk about the
> > implementation deallocation function, and how come the sentence starts
with
> > an "if"? Is there any reason not to call the deallocation function, and
what
> > about my own version of operator delete()?
>
> The implementation deallocation function is, obviously, not called if a
> user-provided version of operator delete is chosen instead.
>
> I interpret the statement above as just a specification of the behaviour
> of the implementation deallocation function. If the implementation
> deallocation function is called and the operand is non-null, the storage
> will be deallocated (imperative!). If it's not called, i.e. a
> user-defined operator delete is called in its place, the standard
> doesn't specify what happens because it can't: the storage may be
> deallocated or not, it's all up to the user who provided the replacement
> function.
>

The standard does define precisely what happens when a user defined operator
delete is called:

3.7.3/3 "Any allocation or deallocation functions defined in a C++ program
shall conform to the semantics defined in 3.7.3.1 and 3.7.3.2"

Best regards,

Matthias Hofmann



---
[ 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:<1Ltzb.161734$vO5.6346206@twister1.libero.it>...
...
> I interpret the statement above as just a specification of the behaviour
> of the implementation deallocation function. If the implementation
> deallocation function is called and the operand is non-null, the storage
> will be deallocated (imperative!). If it's not called, i.e. a
> user-defined operator delete is called in its place, the standard
> doesn't specify what happens because it can't: the storage may be
> deallocated or not, it's all up to the user who provided the replacement
> function.

The standard could, and does, impose requirements upon the replacement
function. 17.3.1.3p4 says: "For non-reserved replacement and handler
functions, Clause 18 specified two behaviors for the functions in
question: their required and default behavior. The _default behavior_
describes a function definition provided by the implementation. The
_required behavior_ describes the semantics of a funtion definition
provided by either the implementation or a C++ program. Where no
distinction is explicitly made in the description, the behavior
described is the required behavior."

The replaceable storage deallocation functions are required to accept
null pointers, and pointers allocated with the corresponding operator
new; but there are no other applicable requirements.

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