Re: Guarantee of side-effect free assignment
On Oct 7, 9:10 pm, jdenn...@acm.org (James Dennett) wrote:
James Kanze wrote:
On Oct 7, 2:21 am, jdenn...@acm.org (James Dennett) wrote:
Alf P. Steinbach wrote:
From discussions in [comp.lang.c++] and [comp.lang.c++.moderated], as
well as articles on the net about concurrency in C++, I'm reasonably
sure that given
#include <iostream>
#include <ostream>
struct S { S(){ throw 123; } int foo(){ return 666; } };
int main()
{
S* p = 0;
try
{
p = new S();
}
catch( ... )
{}
if( p ) { std::cout << p->foo() << std::endl; }
}
..
The assignment cannot occur until the
new value is known, which means that the "new" operator
has returned its result, which means that the object has been
constructed.
The construction of the object is a side effect.
..
The call to the constructor is *not*
a side-effect of evaluating the expression; it's an inherent
part of determining the value of that expression.
I'll quote the draft standard here (I don't know what the current
standard says).
1.9p13
"Evaluation of an expression (or a sub-expression) in general includes
both value computations (including determining the identity of an
object for lvalue evaluation and fetching a value previously assigned
to an object for rvalue evaluation) and initiation of side effects."
5.17p1
"In all cases, the assignment is sequenced after the value computation
of the right and left operands,"
So the question is, is the creation of the object a side-effect (as
James Kanze claims) or part of the value computation (as James Dennett
claims).
5.3.4p1
"If the entity is a non-array object, the new-expression returns a
pointer to the object created."
To have a pointer to an object you must have an object. Therefore
creating the object must be part of the value computation.
As further food for thought, consider
*(new C);
Is that illegal? If the construction is only a side-effect it should
be -- you can't dereference an object which is not yet constructed.
How about
*(new int(4)) = 5;
If construction is a side-effect, this will fall foul of 1.9p16:
"If a side effect on a scalar object is unsequenced relative to ... a
different side effect on the same scalar object ... the behavior is
undefined."
Yechezkel Mett
---
[ 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.comeaucomputing.com/csc/faq.html ]