Re: Guarantee of side-effect free assignment
On Oct 9, 4:53 pm, jdenn...@acm.org (James Dennett) wrote:
James Kanze wrote:
On Oct 7, 9:36 pm, James Dennett <jdenn...@acm.org> wrote:
Alf P. Steinbach wrote:
* James Dennett:
Alf P. Steinbach wrote:
I can find no such guarantee in the standard. It
seems the compiler is free to rewrite
p = new S();
as
p = operator new( sizeof( S ) );
new( p ) S();
What would grant the compiler freedom to deviate in such an
observable way from the semantics of the abstract machine (in
which, I hope it is clear, the rhs of an assignment is evaluated
before its result -- if there is one -- is assumed to be known).
That rule is not only not clear, it seems to be non-existent.
It seems to follow simple logic. The value of an expression
is determined by evaluating that expression.
The same simple logic says that in "j = ++i;", the ++i must
precede the assignment. The standard quite clearly says that
this is *not* the case; that an expression has both a value and
side effects, and that the two are more or less independent.
The standard explicitly says that inspecting i to see if it
has been incremented (without an intervening sequence point)
is undefined. It is *that* which grants it latitude to
deviate from the order which *is* specified.
Even if i and j have types "int volatile", and are observable
from the outside? (The "traditional" interpretation of the C
standard has been that you shouldn't make more than one volatile
access per statement, since the ordering of the accesses within
the statement is not specified.)
It may not be what one wants to hear, but I think that the
standard is quite clear: "Except where noted, the order of
evaluation of operands of individual operators and
subexpressions of individual expressions, AND THE ORDER IN WHICH
SIDE EFFECTS TAKE PLACE, is unspecified." Is there any other
reasonable interpretation in which side effects may take place
after the value of the subexpression has been used?
"At certain specified points in the execution sequence called sequence
points, all side effects of previous evaluations shall be complete and
no side effects of subsequent evaluations shall have taken place."
intro.execution/7]
we can conclude that - at the point when the new-expression makes its
function call - the assignment to p must a) either be over or b) must
have not yet begun. Well, since the value assigned to "p" is dependent
on the value returned by the new-expression, the only possibility is
that the assignment to "p" must fall in the evaluations "not-yet-
started" category. Therefore we are assured that when the function
call is made, p will still have its last-assigned value (the null
In this case, there are sequence points as part of the
evaluation of the new expression (in particular, at the start
and end of the call to operator new, and at the start and end
of the call to a constructor).
The call to the allocator function definitely introduces a
sequence point. The call to the allocator function must also
precede the assignment, since the compiler can have no way of
knowing what the value of the expression is until this call has
occured. The "call" to the "constructor" of a built-in type
(e.g. "new int(42)") does NOT introduce a sequence point, and at
any rate, the standard does not clearly say that the call to the
constructor is part of the "value" of the expression; it would
seem logically to be a side effect, so it's sequence points
aren't relevant.
That's a separate case.
Not really. It's only a special case because we know that the
initialization cannot raise an exception.
The specified semantics still require
that what is returned by new int(42) is a pointer to the newly
created object (an int with value 42), but there is no way for
conforming (single-threaded) code to see whether the assignment
of the result in p = new int(42) occurs before or after the
initialization of the int. (That changes when C++ adds support
for multi-threading, if p is accessible from other threads.)
Your argumentation continues to be based on the idea that the
reordering only takes place because of the as-if rule. The
standard, however, specifically says that it may take place,
i.e. that the abstract machine may reorder as well. (Otherwise,
the statement that the order side effects take place is
irrelevant.)
The example using a constructor still demonstrates that -- in
principle -- initialization is an inherent part of evaluating
a new-expression, not a mere side-effect.
What does "inherent part" mean? I'd certainly say that the
modification of the left hand side in an assignment is an
"inherent part" of the expression, but it's still a side effect.
It may only be a note (and thus non-normative), but I think that
the first paragraph of section 5 makes the intent very clear: "An
expression can result in a value and can cause side effects."
Any modification of the global state of the system is a side
effect, at least according to the definitions I'm aware of.
So the issue is whether the assignment side-effect can be
moved to before those sequence points.
We agree that such a move is observable. I claim that it
violates the notion of evaluation of an expression (a notion
so fundamental that it's not specified by 14882, as the
relevant aspects of it are common to an entire field).
And how does this not apply to the case of "j = ++ i;"
Because of explicit latitude granted by the standard to
implementations in this case, making it impossible for
conforming code to tell. Abstractly the increment happens
first; however, the standard mandates that it's undetectable
if the implementation choose to defer the actual increment.
That statement is neither supported by the actual words in the
standard ("the order in which side effects take place is
unspecified"), nor by any of the traditional interpretations of
the C standard. If i and j have type "int volatile", the order
is observable.
Whether
the modification of i occurs before or after the assignment to j
is potentially observable, e.g. through an asynchronous signal.
Standard C++ doesn't support asynchronous signals.
Standard C certainly does; it doesn't provide a standard means
of generating them, and it doesn't require an implementation to
ever generate them, but it definitely recognizes their
existance, e.g. (?5.1.2.3/4): "When the processing of the
abstract machine is interrupted by receipt of a signal, only the
values of objects as of the previous sequence point may be
relied on. Objects that may be modified between the previous
sequence point and the next sequence point need not have
received their correct values yet."
I think standard C++ more or less includes this by reference.
The intent is definitely that "volatile" have the same meaning
as in C.
An expression can result in a value, and can cause side effects.
As far as I can tell, all that is required (of the abstract
machine) is that those side effects occur before the next
sequence point. That is certainly the traditional
interpretation.
That's a C++-specific definition of "side-effect".
It's actually more or less the definition from C.
Which begs the question: is construction a mere "side effect"?
Which is really the issue, isn't it? The usual definition of a
side effect is something which modifies the program state. A
constructor certainly does that. So does the allocator
function, for that matter. The difference is that the allocator
function (and the standard speaks of it as being a function)
must be called before the value of the expression can be
determined, and calling the function introduces the necessary
sequence points so that any change in global state made within
the function must take place before the return from the
function. If there were any way for the compiler to know what
the value of the new expression was before the allocator
function was called, it could also do that assignment before
calling the allocator function. Since the result of the new
expression *is* the return value of the allocator function
converted to the target type, however, the allocator function
must be called before the value is used. (I don't think the
wording in the orginal C or C++ standards even guaranteed this.
But basic causation does.)
I'll have a closer look at the wording which will replace this
in the next version of the standard.
The question is, of course, whether the call to the
constructor is a side effect, or whether it is a necessary
part of evaluating the value. The most intuitive
interpretation would be that it is a side effect.
I find that interpretation deeply counterintuitive, and indeed
a violation of reason: the value does not even exist if the
constructor throws. Knowing the value is impossible without
knowing whether the constructor throws: therefore, execution
of the constructor is essential to evaluating the expression.
The "value" of a new expression is simply a pointer. It must
"exist" for the compiler to call the constructor.
[...]
Again, I refer to the expression "j = ++ i". If i and j are
initially 0, the above analysis would mean that an asynchronous
signal could see: i==0 && j==0, i==1 && j==0 or i==1 && j==1,
but never i==0 && j==1. This is contrary to the traditional
interpretation of what is allowed in C.
But not to anything written in the standard, I think.
See above. There are at least two relevant statements. The
first, in the definition of expressions, is basically identical
in both standards: "The order [...] of side effects is
unspecified". The second, at least in the C standard, makes it
clear that even volatile doesn't affect this. The reordering is
definitely legal.
[...]
In other words, evaluation of expressions in C++ has two
aspects: (1) determining the value of that expression, and
(2) side-effects (which may modify state, or have otherwise
consequences). The side-effects can be reordered so long
as the semantics of the abstract machine (i.e., the specification
of what things mean in C++) is not violated. Reordering an
assignment to before the value to assign is evaluated is a
violation of these semantics.
I think the above is somewhat of a misstatement.
We disagree, of course.
?5/4 says
quite clearly: "Except where noted, the order of evaluation of
operands of individual operators and subexpressions of
indivitual expressions, AND THE ORDER IN WHICH SIDE-EFFECTS TAKE
PLACE, is unspecified."
Indeed, and that's the backdrop for what I've been trying to
explain. The "Except where noted" is key: the definition of
assignment is, to me, quite explicit in noting the order of
operations. Evidently it wasn't clear enough though.
I don't think it says anything about the actual order. At
least, no more that is said for ++. It says what a new
expression does, i.e. it defines 1) the value of the expression
(type T*, etc.), and 2) the side effects of the expression
(allocator called, memory initialized). It doesn't say anywhere
that those side effects must be complete before the value is
considered available, nor even that the side effects don't obey
the usual rule that allows reordering.
An interesting question:
int *volatile p = NULL ;
int volatile i = 42 ;
int volatile j ;
p = new int( j = i ) ;
Is any order imposed for the writes to p and j?
This refers to the abstract machine:
side effects are not required to take place in the same order
the corresponding sub-expressions are evaluated, except where
noted. What Alf and I can't find is where this is noted for the
side effect of calling a constructor (or executing the
initialization of a built-in type) in a new expression.
Probably an oversight -- one of many things that seemed so
obvious as to not need explicit text, but that experience
has shown to benefit from more clarity.
Agreed. It may have been clear in the minds of the authors, but
in a standard, every i must be dotted.
[...]
Looking over a current draft would be useful then, to check
that the changes more clearly express what we want.
I'll do so. It's possible that the issue has been addressed;
it's (vaguely) related to the problem of double checked locking.
(Except that if it is addressed in that context, the tendency
would be to say that it isn't guaranteed.)
In the presence of threads, much more becomes observable,
and the issue is hugely more complicated. Hopefully the work
done on the C++0x memory model will be sufficient for the MT
case, and hence clearly sufficient for the single threaded
situation.
Except that in the multi-threaded model, it is explicit that
other threads may see writes in a different order unless some
synchronization primitives intervene. In other words, even if
the compiler generates the call to the constructor (and the
writes it contains) before the write to the pointer in the
assignment, there is no guarantee that another thread will see
them in that order. (This is a well known problem, see the
issues surrounding double checked locking. And why it doesn't
work, even in Java, where the order is rigorously guaranteed.)
--
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 ]