Re: Guarantee of side-effect free assignment
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; }
}
there is no guarantee that this code will not end up in a call to
p->foo() with an invalid pointer p, i.e., that might well happen.
Surely that couldn't have been the committee's intention?
I wouldn't imagine so.
Why isn't assignment treated as a function call?
It doesn't need to be. 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.
Can you justify that claim? Alf's example illustrates that
calling the constructor is needed in order to know whether
the expression has a value. The value can't be assigned from
if it does not exist. 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.
The compiler
can use the new value as soon as it knows it. All that the
standard requires is that side effects occur before the next
sequence point.
Right, but not relevant because what we're discussing is not
a side-effect (the only relevant side-effect is the assignment
of the result -- if there is one -- to the pointer p).
If the constructor throws, there's no value from "new" above,
and the assignment cannot occur; p will remain null.
How is this any different from the compiler generating the
actual assignment in ++i after it uses the value?
The quirk in that case is that there are additional rules
citing additional cases as undefined (if there would be
"too many" reads/writes without intervening sequence points).
There's simply no way to write code with defined behavior
that can observe the timing of the increment in ++i without
adding a sequence point such as by writing
void observe(int, int*) { ... }
..
observe(++i,&i);
and as soon as we do that, the sequence point changes things
so that the side-effect must occur before the call to the
function. Naturally the inability to observe the result means
that the "as if" rule allows re-ordering. That does not apply
in the original example in this thread.
-- James
---
[ 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 ]