Slavomir Kaslev wrote:
> Take a look at the following code:
>
> int foobar;
>
> int func() {
>  foobar += 1;
>  return foobar;
> }
>
> int main() {
>  cout << func() << "\t" << func() << "\t" << func() << endl;
> }
>
> I bet all of you expected the output to be 1 2 3.

I'd bet that a large fraction of those reading this on
comp.std.c++ did not have that expectation, though it's
not a typical group.

> Well here is a surprise for you. On Visual C++ 8.0 the output is
> actually 3 2 1.
> Howerever, when one rewrites as:
>
> cout << func() << "\t";
> cout << func() << "\t";
> cout << func() << endl;
>
> the progam behaves as expected.
>
> Is this a compiler bug?

No.  In the latter case there are sequence points at
the end of each full expression (in this case, that
means where the ';' characters are), ensuring that the
function calls occur in the order you expect.  In the
original code, there are no such sequence points, and
the compiler is free to make the calls to func() in any
order: it will output 1, 2 and 3 in some order, but any
of the 3! = 6 orders is acceptable.  The order is
unspecified by the standard.

-- 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                      ]

James Dennett wrote:
>
> There's not a definition of "conforming code" in the
> C++ standard, so far as I am aware.  Implementations
> can be conforming or not; code can be guaranteed to
> work on all conforming implementations, or it can be
> such that it can work with at least one comforming
> implementation.  It can require a diagnostic, or not.
> But I don't think we define "conforming code".

Actually I had been unsure of the term "conforming code";
what would be the appropriate term for a program (code) that
does not incur undefined behaviour and that works in the
intended way across different conforming implementations?

> It would break code which might be known to work with
> one or more specific implementations that define the
> evaluation order as an extension of the C++ standard;
> such implementations can certainly be conforming.

That would just be an implementation-specific code
and the standard doesn't need to worry about it very much
(if the change gives substantial benefit, of course).

>                  While the standardisation process
> can't completely take account of people who ignore
> standards, it should be pragmatic and try to avoid
> gratuitous damage to the industry.

That's true. No unnecessary breaking of existing codes.

> That said, it's possible that the benefit of defined
> evaluation order would be in eliminating far more bugs
> than it introduces -- and as noted above, the bugs it
> would introduce would be in code that was already
> arguably flawed in making non-portable assumptions.

That's true.

> There's another kind of backwards compatibility to
> consider.  It's possible that compilers choose evaluation
> order that generates efficient code for a given ABI.
> There has been much discussion here and elsewhere of
> possible efficiency effects of defined order, with little
> to no hard evidence on either side.  In particular, it's
> unclear to me if this is an issue as we move towards a
> C++ which has better support for parallelism.

Neither do I think we should introduce a specified order;
not to depend on the unspecified order is just a matter of
education and I don't think it is a significant problem.

--
Seungbeom Kim

---
[ 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                      ]

On Wed,  5 Apr 2006 22:36:46 GMT, hickin@nortel.com ("John Hickin")
wrote:

> "Slavomir Kaslev" <slavomir.kaslev@gmail.com> wrote in message
> news:1144239601.906610.191930@u72g2000cwu.googlegroups.com...

> > int foobar;

> > int func() {
> > foobar += 1;
> > return foobar;
> > }

> > int main() {
> > cout << func() << "\t" << func() << "\t" << func() << endl;
> > }

> With X(x,y) standing for x.operator<<(y) this is (more or less) equivalent
> to

>   X(X(X(cout,++foobar), ++foobar, ++foobar);
>   ------------------------------------^^^^^^^

Not equivlent at all.  The original code has unspecified behavior which
must produce some permutation of 1 2 3 as output.  Your rewrite
introduces undefined behavior because the three ++ operations may now be
evaluated in paralell modifying an object three times with no sequence
point.  Since prefix ++ returns a reference, the expected output for the
modification might be 3 3 3.  If you just change the return of func to
int&, that is one of the now sixteen not six acceptable unspecified
results.

> I see no reason why it cannot evaluate ++foobar as 1 and pass that to the
> outer X; there is no constraint on whether or not x is evaulated before y in
> X(x,y).

Agreed.

John

---
[ 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                      ]

Slavomir Kaslev wrote:
> Take a look at the following code:
>
> int foobar;
>
> int func() {
>  foobar += 1;
>  return foobar;
> }
>
> int main() {
>  cout << func() << "\t" << func() << "\t" << func() << endl;
> }
>
> I bet all of you expected the output to be 1 2 3.
> Well here is a surprise for you. On Visual C++ 8.0 the output is
> actually 3 2 1.

I think this program has undefined behaviour, because it modifies
the stored value of a single object multiple times between consecutive
sequence points. Therefore, the output can be anything, not just
"1 2 3" or "3 2 1" or "2 3 1" (or whatever).

--
Seungbeom Kim

---
[ 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                      ]

Gene Bushuyev wrote:
> "James Dennett" <jdennett@cox.net> wrote in message
> news:XwTYf.7386$Fo3.5124@fed1read01...
> [...]
>> There are periodically requests to nail down a specific order
>> of evaluation for C++.  One problem with doing so is that it
>> may well change the behaviour of code that currently works
>> with a specific compiler, so that if the compiler is updated
>> to change its order of evaluation the software will break.
>
> Specified behavior is one particular case of unspecified behavior. So specifying
> the evaluation order can break no standard compliant program.

The standard doesn't say what it means for a user's program
to be "compliant".  It doesn't dismiss programs that rely on
unspecified or implementation-defined behaviour as being
incorrect/non-compliant -- it just doesn't guarantee their
behaviour.  Implementations may offer stronger promises.

> Expectation of a
> non-compliant program to "work" on a compliant compiler is and always was
> unreasonable.

And yet the program may well work, reliably, given a compiler
that specifies a particular order *today*, and would cease to
work if compiled with a future compile which changed that order
to conform to an updated standard.

We can argue all day about the wisdom (or lack thereof) in
writing code which depends on non-portable behaviour, but that
won't change the fact that much code does this, and some of
that code is reliable in its current environment.

-- 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                      ]

James Dennett wrote:
>
> We can argue all day about the wisdom (or lack thereof) in
> writing code which depends on non-portable behaviour, but that
> won't change the fact that much code does this, and some of
> that code is reliable in its current environment.

It should not be the province of the standard to protect code which
relies on implementation specific behavior by not making an appropriate
change which in other respects would be deemed good. If that were the
case then nothing in the standard which related to unspecified behavior
could ever be changed and would have to remain in stasis as long as the
C++ language existed.

---
[ 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                      ]

Seungbeom Kim wrote:

> James Dennett wrote:
>>
>> There's not a definition of "conforming code" in the
>> C++ standard, so far as I am aware.  Implementations
>> can be conforming or not; code can be guaranteed to
>> work on all conforming implementations, or it can be
>> such that it can work with at least one comforming
>> implementation.  It can require a diagnostic, or not.
>> But I don't think we define "conforming code".
>
> Actually I had been unsure of the term "conforming code";
> what would be the appropriate term for a program (code) that
> does not incur undefined behaviour and that works in the
> intended way across different conforming implementations?
>
Perhaps the term used for such code in the C standard can be used.
In the C standard, code that uses only the features defined by the
standard, and whose output does not depend on unspecified,
implementation-defined or undefined behaviour, is called "strictly
conforming" code.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

---
[ 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                      ]

"Bart van Ingen Schenau" <bart@ingen.ddns.info> wrote in message
news:123f8qd9ong49ab@corp.supernews.com...

> Seungbeom Kim wrote:
>
>> James Dennett wrote:
>>>
>>> There's not a definition of "conforming code" in the
>>> C++ standard, so far as I am aware.  Implementations
>>> can be conforming or not; code can be guaranteed to
>>> work on all conforming implementations, or it can be
>>> such that it can work with at least one comforming
>>> implementation.  It can require a diagnostic, or not.
>>> But I don't think we define "conforming code".
>>
>> Actually I had been unsure of the term "conforming code";
>> what would be the appropriate term for a program (code) that
>> does not incur undefined behaviour and that works in the
>> intended way across different conforming implementations?
>>
> Perhaps the term used for such code in the C standard can be used.
> In the C standard, code that uses only the features defined by the
> standard, and whose output does not depend on unspecified,
> implementation-defined or undefined behaviour, is called "strictly
> conforming" code.

The C++ Standard made a point of deviating from C in this regard.
So no, you *can't* use the sensible definition from the C Standard.
It has no meaning in C++.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://www.comeaucomputing.com/csc/faq.html                      ]

Edward Diener No Spam wrote:

>
> It should not be the province of the standard to protect code which
> relies on implementation specific behavior by not making an appropriate
> change which in other respects would be deemed good.

Language changes that break existing code are hightly suspect.

> If that were the
> case then nothing in the standard which related to unspecified behavior
> could ever be changed and would have to remain in stasis as long as the
> C++ language existed.
>

Not really. Saying that A is a bad thing to do is not the same as saying
that A cannot ever be done.

--

Pete Becker
Roundhouse Consulting, Ltd.

---
[ 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                      ]

Pete Becker wrote:
> Language changes that break existing code are hightly suspect.

So are there any C++ compilers which specify and document their
order of evaluation so that programs may rely upon it?

---
[ 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                      ]

On Fri,  7 Apr 2006 03:27:56 GMT, musiphil@bawi.org (Seungbeom Kim)
wrote:

> Slavomir Kaslev wrote:

> > Take a look at the following code:

> > int foobar;
> > int func() {
> >  foobar += 1;
> >  return foobar;
> > }
> > int main() {
> >  cout << func() << "\t" << func() << "\t" << func() << endl;
> > }

> > I bet all of you expected the output to be 1 2 3.
> > Well here is a surprise for you. On Visual C++ 8.0 the output is
> > actually 3 2 1.

> I think this program has undefined behaviour, because it modifies
> the stored value of a single object multiple times between consecutive
> sequence points. Therefore, the output can be anything, not just
> "1 2 3" or "3 2 1" or "2 3 1" (or whatever).

Nope.  There are lots of sequence points here.  Note that func() is two
sequence points, one at call and another at return.  Calls within an
expression may be executed in any order, but not in paralell.  This
provides two sequence points in addition to the one at the end of the
statement within the function between modifications of foobar.  It is
unspecified behavior and must produce a permutation of 1 2 3.

John

---
[ 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                      ]

Seungbeom Kim wrote:
> Slavomir Kaslev wrote:
> > Take a look at the following code:
> >
> > int foobar;
> >
> > int func() {
> >  foobar += 1;
> >  return foobar;
> > }
> >
> > int main() {
> >  cout << func() << "\t" << func() << "\t" << func() << endl;
> > }
> >
> > I bet all of you expected the output to be 1 2 3.
> > Well here is a surprise for you. On Visual C++ 8.0 the output is
> > actually 3 2 1.
>
> I think this program has undefined behaviour, because it modifies
> the stored value of a single object multiple times between consecutive
> sequence points. Therefore, the output can be anything, not just
> "1 2 3" or "3 2 1" or "2 3 1" (or whatever).

No.  There's a sequence point on entry to func (actually, I think on
completely evaluating all its non-existent arguments), and another on
reaching the end of the statement where the global is incremented.

So the behaviour is unspecified, not undefined.

---
[ 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                      ]

===================================== MODERATOR'S COMMENT:

I'm approving this because it's relevant to what the C++ standard says abou=
t
sequence points. Let's make sure to keep the discussion focused on the
standard and not on particular compilers.

------=_Part_2107_28556611.1144249692604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

approve<br>
comment<br>
I'm approving this because it's relevant to what the C++ standard says
about sequence points. Let's make sure to keep the discussion focused
on the standard and not on particular compilers.<br>

------=_Part_2107_28556611.1144249692604--


===================================== END OF MODERATOR'S COMMENT
Take a look at the following code:

int foobar;

int func() {
 foobar += 1;
 return foobar;
}

int main() {
 cout << func() << "\t" << func() << "\t" << func() << endl;
}

I bet all of you expected the output to be 1 2 3.
Well here is a surprise for you. On Visual C++ 8.0 the output is
actually 3 2 1.
Howerever, when one rewrites as:

cout << func() << "\t";
cout << func() << "\t";
cout << func() << endl;

the progam behaves as expected.

Is this a compiler bug?

---
[ 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                      ]

Slavomir Kaslev wrote:

> Take a look at the following code:
>
> int foobar;
>
> int func() {
> foobar += 1;
> return foobar;
> }
>
> int main() {
> cout << func() << "\t" << func() << "\t" << func() << endl;
> }
>
> I bet all of you expected the output to be 1 2 3.
> Well here is a surprise for you. On Visual C++ 8.0 the output is
> actually 3 2 1.
> Howerever, when one rewrites as:
>
> cout << func() << "\t";
> cout << func() << "\t";
> cout << func() << endl;
>
> the progam behaves as expected.
>
> Is this a compiler bug?

No, it is not.
In the statement
  cout << func() << "\t" << func() << "\t" << func() << endl;
there are no sequence points that specify an ordering for the calls to
func(), so the compiler is allowed to make the three calls to func() in
any order it likes.
As the evaluation order is unspecified, any sequence of the numbers 1, 2
and 3 (separated by tabs) is valid output for this statement.

The output of "3 2 1" is not even that odd, if you take this,
semantically equivalent, version of the output statement (I abbreviated
the keyword 'operator' to 'op' for readability):
  op<<(op<<(op<<(op<<(op<<(op<<(cout, func()), "\t"), func()), "\t"),
func()),  endl);
If in this representation, the arguments to the nested calls are
evaluated right-to-left and outer-to-inner, then the expected output is
"3 2 1". This evaluation order is quite natural if the calling
convention of the platform calls for putting the arguments in
right-to-left order on the stack.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/

---
[ 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                      ]

Slavomir Kaslev wrote:
> Take a look at the following code:
>
> int foobar;
>
> int func() {
>  foobar += 1;
>  return foobar;
> }
>
> int main() {
>  cout << func() << "\t" << func() << "\t" << func() << endl;
> }
>
> I bet all of you expected the output to be 1 2 3.
> Well here is a surprise for you. On Visual C++ 8.0 the output is
> actually 3 2 1.
> Howerever, when one rewrites as:
>
> cout << func() << "\t";
> cout << func() << "\t";
> cout << func() << endl;
>
> the progam behaves as expected.
>
> Is this a compiler bug?

No, it is not.  In the first case, there are no sequence
points between the calls to func(), and the compiler is
allowed to make the calls in any order.  In the second case,
there is a sequence point at the end of each full expression,
i.e., at each semi-colon, and the compiler is constrained to
call each func() in the order their results are displayed.

If your functions have side-effects, you need to make sure
you include sufficiently many sequence points to guarantee
the constraints you want on their order of execution.

There are periodically requests to nail down a specific order
of evaluation for C++.  One problem with doing so is that it
may well change the behaviour of code that currently works
with a specific compiler, so that if the compiler is updated
to change its order of evaluation the software will break.
There are other issues, that I'd prefer not to rehash; a
search via Google can dig up the old threads.

-- 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                      ]

Slavomir Kaslev wrote:

> Take a look at the following code:
>
> int foobar;
>
> int func() {
>   foobar += 1;

Side-effect.

>   return foobar;
> }
>
> int main() {
> cout << func() << "\t" << func() << "\t" << func() << endl;
> }
>
> I bet all of you expected the output to be 1 2 3.
> Well here is a surprise for you. On Visual C++ 8.0 the output is
> actually 3 2 1.

Not only on VC++8.0. Even more surprising:

  cout << func() << ":"
       << func() << "::"
       << func() << ":::"
       << foobar << endl;

yields:

  3:2::1:::0

Simplified:

  cout << func() << func();

yields:

  21

instead of what one would expect:

  12

> Howerever, when one rewrites as:
>
> cout << func() << "\t";
> cout << func() << "\t";
> cout << func() << endl;
>
> the progam behaves as expected.
>
> Is this a compiler bug?

I don't think so. First, there is the side-effect of incrementing foobar,
which is sort of unexpected if you perform an operation that implies that
it only reads values, second, you need to realize that you can rewrite as
follows:

  cout << c; ==> cout.operator<<(c);

so, similarly:

  cout << c << c; ==> cout.operator(c).operator(c);

Then substitute func() for c:

  cout << func() << func(); ==> cout.operator<<(func()).operator<<(func());

You can see from the latter form that it is different and has a different
order of evaluation than expected and also a different order of evaluation
as:

  cout << func();
  cout << func();

--
Ruurd
.o.
.o
ooo

---
[ 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                      ]

"Slavomir Kaslev" <slavomir.kaslev@gmail.com> wrote in message
news:1144239601.906610.191930@u72g2000cwu.googlegroups.com...
> int foobar;
>
> int func() {
> foobar += 1;
> return foobar;
> }
>
> int main() {
> cout << func() << "\t" << func() << "\t" << func() << endl;
> }
>
With X(x,y) standing for x.operator<<(y) this is (more or less) equivalent
to

  X(X(X(cout,++foobar), ++foobar, ++foobar);
  ------------------------------------^^^^^^^

I see no reason why it cannot evaluate ++foobar as 1 and pass that to the
outer X; there is no constraint on whether or not x is evaulated before y in
X(x,y).

Regards, John.


---
[ 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                      ]

James Dennett wrote:
>
> There are periodically requests to nail down a specific order
> of evaluation for C++.  One problem with doing so is that it
> may well change the behaviour of code that currently works
> with a specific compiler, so that if the compiler is updated
> to change its order of evaluation the software will break.

It certainly may change the behaviour of existing codes, but
can it break existing conforming codes? I doubt it, because a
conforming code is not supposed to depend on any specific order
of evaluation (between any consecutive sequence points, of course).

--
Seungbeom Kim

---
[ 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                      ]

Seungbeom Kim wrote:
> James Dennett wrote:
>> There are periodically requests to nail down a specific order
>> of evaluation for C++.  One problem with doing so is that it
>> may well change the behaviour of code that currently works
>> with a specific compiler, so that if the compiler is updated
>> to change its order of evaluation the software will break.
>
> It certainly may change the behaviour of existing codes, but
> can it break existing conforming codes? I doubt it, because a
> conforming code is not supposed to depend on any specific order
> of evaluation (between any consecutive sequence points, of course).

There's not a definition of "conforming code" in the
C++ standard, so far as I am aware.  Implementations
can be conforming or not; code can be guaranteed to
work on all conforming implementations, or it can be
such that it can work with at least one comforming
implementation.  It can require a diagnostic, or not.
But I don't think we define "conforming code".

Defining evaluation order would not break existing
code whose behaviour is  guaranteed by the standard
to be portable across all conforming implementations.

It would break code which might be known to work with
one or more specific implementations that define the
evaluation order as an extension of the C++ standard;
such implementations can certainly be conforming.

Outside of the standards world, many programmers and
many organisations consider their code to be "good"
if it passes its tests and keeps their customers happy,
and their knowledge of the ISO C++ Standard is often
patchy at best.  While the standardisation process
can't completely take account of people who ignore
standards, it should be pragmatic and try to avoid
gratuitous damage to the industry.

That said, it's possible that the benefit of defined
evaluation order would be in eliminating far more bugs
than it introduces -- and as noted above, the bugs it
would introduce would be in code that was already
arguably flawed in making non-portable assumptions.

There's another kind of backwards compatibility to
consider.  It's possible that compilers choose evaluation
order that generates efficient code for a given ABI.
There has been much discussion here and elsewhere of
possible efficiency effects of defined order, with little
to no hard evidence on either side.  In particular, it's
unclear to me if this is an issue as we move towards a
C++ which has better support for parallelism.

-- 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                      ]

"James Dennett" <jdennett@cox.net> wrote in message
news:XwTYf.7386$Fo3.5124@fed1read01...
[...]
> There are periodically requests to nail down a specific order
> of evaluation for C++.  One problem with doing so is that it
> may well change the behaviour of code that currently works
> with a specific compiler, so that if the compiler is updated
> to change its order of evaluation the software will break.

Specified behavior is one particular case of unspecified behavior. So specifying
the evaluation order can break no standard compliant program. Expectation of a
non-compliant program to "work" on a compliant compiler is and always was
unreasonable.

> There are other issues, that I'd prefer not to rehash; a
> search via Google can dig up the old threads.

I assume, when providing an example to prove your point, you chose the strongest
one. Therefore there is no need to refer to unnamed weaker examples.

--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
There is no greatness where there is no simplicity, goodness and truth. ~ Leo
Tolstoy

---
[ 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                      ]