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; }
}
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?
What else can it be? Unless it's trivial (which doesn't really
concern us here), it writes to memory, etc. Those are side
effects; the "value" of an expression has no side effects.
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 "value" of a new expression is the pointer returned from the
allocator function. The compiler needs to know this in order to
call the constructor.
It is in every way like the expression ++i. The modification of
i is a side effect; the value of the expression is the value
which will be written, and is available before the side effect
takes place (and must be available, for the side effect to take
place).
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.
How can that be? A constructor doesn't return a value.
[...]
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
It affects the values you might see in the handler of an
asynchronous signal. (And I know, there are a lot of weasel
words there, limiting what you can legitimately do.)
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.
You don't need the "as if" rule. The standard explicitly states
that "side effects" can take place in any order, not necessarily
the order in which the sub-expressions which cause them are
evaluated. And that applies to the abstract machine; the "as
if" rule is not necessary.
The real question, of course, is whether calling the constructor
is a side effect. To be frank, I don't really see how it can be
considered anything else, given the usual meaning of side
effect. Could you elaborate why it isn't a "side effect".
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
---
[ 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 ]