Re: Guarantee of side-effect free assignment
James Kanze wrote:
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?
Part of the evalation of the expression, used to determine
the result of the expression (as indeed it does).
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.
No; it is the address of a newly created object, according
to the standard. If a constructor throws, there is no such
object, and the new expression does not have a value.
The compiler needs to know this in order to
call the constructor.
It is in every way like the expression ++i.
I've talked about the differences. Claiming that they don't
exist doesn't make it so.
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.
It doesn't need to return a value to affect the result of
evaluating an expression. There are plenty of ways in which
even void-returning function can affect the value of an
expression.
[...]
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.
Such an extended interpretation of the freedom to rearrange
code would be most problematic; I can see why people are concerned,
if they think implementors would really do such things.
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".
I believe I've tried to do so: it is *impossible* to determine
the result of a new expression while ignorant of the body of
a constructor which is used by that new expression.
-- 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 ]