Does anyone know why this code from the C++ Standard that used to be
undefined in the Dec96 draft is now unspecified:
[5 (4) ]
        i = v[i++];      // the behavior is unspecified
        i = ++i + 1;     // the behavior is unspecified

It states that :

5(4) 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.  Between the  previ-
  ous  and  next  sequence  point  a scalar object shall have its stored
  value modified at most once by the evaluation of an expression.   Fur-
  thermore,  the  prior  value  shall  be accessed only to determine the
  value to be stored.  The requirements of this paragraph shall  be  met
  for  each  allowable  ordering of the subexpressions of a full expres-
  sion; otherwise the behavior is undefined.


Since in both these expressions the value of 'i' is modified twice
without intervening sequence points, the behavior should be undefined.

The assumption I am making of course is that 'i' and 'v' are
NOT user defined types with overloaded operators.
Could it be that this assumption is inappropriate and is causing this
confusion?

Any clarification will be greatly appreciated.
-Thank You.
-Fais


--
Faisal Vali  fvali@biotrack.com
Software Engineer Identix Biometric Security
WWW: http://www.identix.com
-------------------------------------------------------
Literature always anticipates life. It does not copy it, but moulds it
to its purpose. The nineteenth century, as we know it, is largely an
invention of Balzac. (Oscar Wilde)


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Thanatos <fvali@biotrack.com> writes:

>Does anyone know why this code from the C++ Standard that used to be
>undefined in the Dec96 draft is now unspecified:
>[5 (4) ]

That's Chapter 5, paragraph 4.

>        i = v[i++];      // the behavior is unspecified
>        i = ++i + 1;     // the behavior is unspecified

>It states that :

>5(4) 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.  Between the  previ-
>  ous  and  next  sequence  point  a scalar object shall have its stored
>  value modified at most once by the evaluation of an expression.   Fur-
>  thermore,  the  prior  value  shall  be accessed only to determine the
>  value to be stored.  The requirements of this paragraph shall  be  met
>  for  each  allowable  ordering of the subexpressions of a full expres-
>  sion; otherwise the behavior is undefined.


>Since in both these expressions the value of 'i' is modified twice
>without intervening sequence points, the behavior should be undefined.

You omitted the part that shows that the example code is an
Example. Examples are not normative (that is, they are not part
of the language definition.).

Notice the last sentence of the paragraph you quoted, which IS
normative, says the code has undefined results.

It would probably be better if the comments in the example
said "undefined" instead of "unspecified".

--
Steve Clamage, stephen.clamage@sun.com


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <368AA7B9.9A4B011E@biotrack.com>, Thanatos
<fvali@biotrack.com> writes
>Does anyone know why this code from the C++ Standard that used to be
>undefined in the Dec96 draft is now unspecified:
>[5 (4) ]
>        i = v[i++];      // the behavior is unspecified
>        i = ++i + 1;     // the behavior is unspecified

First, these lines appear in an example and so are not normative.
Second, I think the change happened as part of the work of trying to
model the operators for builin's in terms of function calls (as for user
defined's).

Frankly, I think we are in a mess here (others can explain why I am
wrong, I hope) because for user defined overloads of increment and
decrement operators there are sequence points that remove the
undefinedness and at worst leave unspecified behaviour but the original
C decision for builtins was not just being awkward for the sake of it.
If the process of writing is not atomic then two wittes can become
intertwined.



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <O83kVNAZl1i2EwD9@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>
>In article <368AA7B9.9A4B011E@biotrack.com>, Thanatos
><fvali@biotrack.com> writes
>>Does anyone know why this code from the C++ Standard that used to be
>>undefined in the Dec96 draft is now unspecified:
>>[5 (4) ]
>>        i = v[i++];      // the behavior is unspecified
>>        i = ++i + 1;     // the behavior is unspecified
>
>First, these lines appear in an example and so are not normative.

While examples may not be normative, examples that directly contradict the
text should really be fixed.  They'll cause many readers to go on a wild
goose chase through the text, looking for the explanation for the example
behavior.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]