Re: post and pre-increment operator overloading not behaving like
intrinsic types. inc:EXAMPLE (please help)
On Nov 21, 1:44 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
On Nov 21, 6:52 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
simudr...@gmail.com wrote:
//hi maybe helpful others can look at this code and
//tell me why the class code won't behave like
//intrinsic types with post and pre increment
[snip]
IntWrapper test1 = test + test++;
int test2 = i + i++;
//test1 should be the same as test2 but they are not
As far as I can see you have unspecified behavior according to
clause [5/4] of the standard.
Not unspecified. Undefined. At least in the second line.
Well, I don't see a variable that has its value modified twice
between sequence points. So it must be the condition
"Furthermore, the prior value shall be accessed only to
determine the value to be stored."
and I have to admit that I never have been able to figure out
the meaning of this sentence.
It could be clearer, but what it basically means is that if you
modify the variable, the only legal accesses without an
intervening sequence point are those which are used to determine
the new value. Intuitively, if there is no sequence point, then
cause and effect ordering may still render the code legal: in an
expression like "a = a + 1", there may not be a sequence point
between the two accesses to a, but it's quite clear that the
read must be occur before the write, since we can't know what to
write until the read has occured.
In some ways, the rule is very much like the rule for accessing
in a multithreaded environment: if any access is a modification,
then all accesses must be "protected". Here, the protection may
be provided by an intervening sequence point, or by a strict
value dependency.
IMHO, the word "prior" in the quoted sentence only causes
confusion. In an expression such as "i + i++", does the first i
access the "prior" value, or some later value. In fact, the
standard states elsewhere that there is undefined behavior is
any legal ordering would result in undefined behavior. Since
the ordering which evaluates the left hand side of the +
operator first does access the "prior" value, the expression has
undefined behavior. But as there are no cases without an
intervening sequence point which don't allow such reordering,
the "prior" is really not needed.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34