Re: Guarantee of side-effect free assignment
On Oct 7, 9:04 pm, jdenn...@acm.org (James Dennett) wrote:
James Kanze wrote:
[...]
The lack of any sequence points, and the fact that calling the
constructor is a "side effect"; the "value" of the expression
may be known before it is called.
Here's where I disagree. The value of the new-expression cannot
be known without calling the constructor; it is no mere side
effect.
Why do you claim that? If I write something like "new int(42)",
are you saying that the fact that 42 is written to the int is
not a side effect, but part of the "value" of the expression?
[...]
In something like:
j = ++ i ;
there is (intentionally) definitely no requirement that the
change in i's value (a side effect) occur before the assignment
to j. And the C standard was carefully worded to make any code
which could detect the difference undefined behavior. In the
case of operator new, in C++, we have a lot more complex side
effects---the constructor is called---but basically, up to a
point, the same rule applied: there was no way a conforming
program could tell, so it didn't matter. Exceptions change
that. Suppose, in the expression above, the modification to the
value of i *could* trigger an exception. Would you say that we
are guaranteed that j is unmodified if this exception occured?
I don't think so.
If ++i is a function call (so that it can thrown an exception
without undefined behavior) then yes, it is guaranteed by the
existing text of 14882:2003 combined with standard terminology
in the field. There's not a value to assign if the RHS throws
an exception.
The problem is, of course, constructing any other case where the
effect can be seen by a conformant program, without invoking
undefined behavior. The closest I can come is what can be seen
by an asynchronous signal which occurs in "j = ++i" (supposing
that j and i have the type sig_atomic_t volatile, to ensure
defined behavior according to the standard). In that case, my
interpretation of the standard is that, assuming i and j
initialized to 0, it is fully conformant for the signal handler
to see i==0 and j==1.
The real problem, of course, is that exceptions really require
specifying the order of evaluation much more strictly.
I don't think that's an issue, but it would be interesting to
know why you think it is.
The allow interrupting an expression at a point where it is
partially executed. To get a "snapshot", so to speak, within an
expression.
Which I
very definitely favor, but which is a road I don't think the
committee wants to take.
The changes from "sequence point" based to a more causal model
for terminology in the standard might address these concerns
to some extent. You opinion on the new form of wording would
be valuable.
I will definitely look at it, although I don't have much time at
present. If nothing else (but I hope to be able to react
before), I'll participate in the formulation of the French
comments on the CD---and threading, and everything tied to it,
are one of my major concerns.
--
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 ]