There is no requirement that the compiler evaluates the function calls in any
given order. Execution order is controlled by sequence points and there are none
between these calls.

7801@e.aarhus.ih.dk wrote:

[ mod note: excessive quoting deleted. -sdc ]

>cout (stream <<) - Is this a bug?
>
>Is there anyone out there who knows if this is a bug or what's the
>problem?????
>
>
>void main()
>{
> cout << f() << f() << f() << endl;
>}
>
>Expected result:
>012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!
>
>The result is:
>210


--
richard_damon@iname.com (Redirector to my current best Mailbox)
rdamon@beltronicsInspection.com (Work Adddress)
Richad_Damon@msn.com (Just for Fun)


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

Wolfgang Bangerth wrote:
>
> 7801@e.aarhus.ih.dk wrote:
>
> > cout (stream <<) - Is this a bug?
> >
> > int f()
> > {
> >         static i=0;
> >
> >         return i++;
> > }
> >
> > void main()
> > {
> >         cout << f() << f() << f() << endl;
> > }
> >
> > Expected result:
> > 012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!
> >
> > The result is:
> > 210

[... explanation snipped ...]

> If you want to get a certain order, write
>   cout << f();
>   cout << f();
>   cout << f() << endl;

Another way would be to move the increment itself to the operator<<
(the three operator<< are IMHO guaranteed to be called in left to right
order, since the result of the first is an argument to the second
and so on), by doing s.th. like this:

class Incrementer
{
  friend Incrementer f();
  friend ostream operator<<(ostream&, Incrementer const&)
  int* p;
  Incrementer(int* P): p(P) {}
  int increment() const { return (*p)++; }
}

ostream& operator<<(ostream& os, Incrementer const& i)
{
  return os << i.increment();
}

Incrementer f()
{
  static int i=0;
  return Incrementer(i);
}

int main()
{
  cout << f() << f() << f() << endl; // should give 012 on every
compiler
}
---
[ 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              ]

7801@e.aarhus.ih.dk wrote:
>
> cout (stream <<) - Is this a bug?
>
> int f()
> {
>   static i=0;
>   return i++;
> }
>
> void main()
> {
>   cout << f() << f() << f() << endl;
> }
>
> Expected result:
> 012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!
>
> The result is:
> 210

Hi,
I tested Your sample with three compilers:

IBM VisualAge C++ 3.0 for OS/2 - result: 012

IBM xlC 1.02 for AIX           - result: 012

GNU g++ 2.7.2 for AIX          - result: 012

As You can see, there is no problem at all
if one use the right compiler :-)


BTW it must be int main() instead of void main()

--
Ryszard Kabatek     ,,,
                   (o o)
---------------o00--(_)--00o---------------
---
[ 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              ]

7801@e.aarhus.ih.dk wrote:

> cout (stream <<) - Is this a bug?
>
> int f()
> {
>         static i=0;
>
>         return i++;
> }
>
> void main()
> {
>         cout << f() << f() << f() << endl;
> }
>
> Expected result:
> 012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!
>
> The result is:
> 210

This is not a bug, but it isn't a feature either. The order of evaluation of
the
three calls to f() is not specified in the standard (though it is noted that
it is
not specified) and you really shouldn't try to use such functions with side
effects
if the order is relevant. In the end, the problem is the same if you write
  int i=0;
  cout << i++ << i++;
in which case everyone sees that there may be a problem (when using f(),
you can only know the problem if you've got the source of f()).

If you want to get a certain order, write
  cout << f();
  cout << f();
  cout << f() << endl;

Regards
  Wolfgang Bangerth
---
[ 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              ]

This behaviour is correct. The statements c << x << y << z binds as
((c<<x)<<y<<z), which ensures that the correct output is produced. The order
in which the sub-expressions x, y and z are evaluated is undefined, so you
should not write code depending on that order.

You should either write:

    c << x;
    c << y;
    c << z;

or you could introduce temporaries:

    tx = x;
    ty = y;
    tz = z;
    c << tx << ty << tz;

Hope this helps!

Silvio Bierman


7801@e.aarhus.ih.dk <7801@e.aarhus.ih.dk> wrote in message
<353ba230.1055415@news.uni-c.dk>...
>cout (stream <<) - Is this a bug?
>
>Is there anyone out there who knows if this is a bug or what's the
>problem?????
>
>Problem:
>
>Statement:
>cout << "a" << "b" << "c" << endl;
>
>Output:
>abc // of course! ;-)
>
>
>Then one whould expect this statement/code to give the following
>result:
>
>int f()
>{
> static i=0;
>
> return i++;
>}
>
>void main()
>{
> cout << f() << f() << f() << endl;
>}
>
>Expected result:
>012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!
>
>The result is:
>210
>
>
>Comments:
>If you debug the code, it looks like that the compiler makes the 3
>function-calls and placing
>there return values on a stack. It then "pops" the values one by one
>"sending" them to the (<<)
>the stream-operator. Which - of course - provides the "wrong" (at
>least that my opinion ;-) )
>result/code.
>
>I've test the code on MSVC 5.0 and BC4.52, which both gives the wrong
>result (2,1,0).
>I've heard that's not a problem with Unix compiler's, but I don't know
>if it's true.
>If you have the solution or any comments to the problem, please
>comment it or e-mail me. THANKS!
>
> Regards
> Bryske
>
>
>[ 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              ]
>
---
[ 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              ]

7801@e.aarhus.ih.dk wrote:
 > int f()
 > {
 >         static i=0;
 >
 >         return i++;
 > }
 >
 > void main()
 > {
 >         cout << f() << f() << f() << endl;
 > }
 >
 > Expected result:
 > 012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!
 >
 > The result is:
 > 210

As there are no sequence points, the compiler is allowed to make the
three calls to f() in any order it likes - the order of evaluation is
undefined.

Paul

P.S. Your main is defined wrongly.


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

7801@e.aarhus.ih.dk <7801@e.aarhus.ih.dk> wrote in message
<353ba230.1055415@news.uni-c.dk>...
>
>Then one whould expect this statement/code to give the following
>result:
>
>int f()
>{
> static i=0;
> return i++;
>}
>
>void main() { cout << f() << f() << f() << endl; }
>
>Expected result:
>012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!
>
>The result is:
>210


The order of evaluation within a statement is not guaranteed.

cerr << a() << b();

Is
( cerr.op<<(a()) ).op<<( b() );
   ^^^^^^^^^^^                ^^
  this                 and          this
must be evaluated before the
second op<<(), but whether the right most b()
is evaluated or the first cerr.op<<(a()) is evaluated
first is not defined. Note that the op<<() functions
will be called in the right order (left then right) but
that still doesn't guarantee that a() is called before
b(). This is just a slightly more complex form of:

f(++i, ++i)

Sam


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

The expression evaluation in C/ C++ is weak ordered, it depends on the compiler.
This doesn't affect operator precedence only when it is undefined the compiler
can handle it in its own way.
Example:
x= (a+b) / (c-d);
then it depends on the compiler if it first calculates a+b and then c-d before
divides or first c-d and then a+b. This may cause unexpected results when
a function changes the values it uses. You can avoid this by using the comma
operator which is left-to-right execution order guranteed, or by placing the
expression in several Statements:
int i=0;
cout<<i++, cout<<i++, cout<<i++; //or
cout<<i++;
cout<<i++;

 greetings Christian

on reply replace "AT" in email address



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

On 23 Apr 98 18:06:46 GMT, Wolfgang Bangerth
<wolf@gaia.iwr.uni-heidelberg.de> wrote:

>7801@e.aarhus.ih.dk wrote:
>
>> cout (stream <<) - Is this a bug?
>>
>> int f()
>> {
>>         static i=0;
>>
>>         return i++;
>> }
>>
>> void main()
>> {
>>         cout << f() << f() << f() << endl;
>> }
>>
>> Expected result:
>> 012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!
>>
>> The result is:
>> 210
>
>This is not a bug, but it isn't a feature either. The order of evaluation of
>the
>three calls to f() is not specified in the standard (though it is noted that
>it is
>not specified) and you really shouldn't try to use such functions with side
>effects
>if the order is relevant. In the end, the problem is the same if you write
>  int i=0;
>  cout << i++ << i++;
>in which case everyone sees that there may be a problem (when using f(),
>you can only know the problem if you've got the source of f()).
>
>If you want to get a certain order, write
>  cout << f();
>  cout << f();
>  cout << f() << endl;

One quibble.

 cout << f() << f() << f() << endl;

is not the same problem as

 cout << i++ << i++ << i++ << endl;

The order of evaluation is unspecified, so the first may print out any
permutation of 012.

The second results in undefined behavior since i is modified more than
once between sequence points; anything can happen.  Nothing may be
printed out.  Or 123456 may be printed out. Or the program may crash.
There are no requirements.
--
Michael M Rubenstein
---
[ 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 <353F273A.40E84EAD@gaia.iwr.uni-heidelberg.de>#1/1,
  Wolfgang Bangerth <wolf@gaia.iwr.uni-heidelberg.de> wrote:
>
> 7801@e.aarhus.ih.dk wrote:
>
> > cout (stream <<) - Is this a bug?
> >
> > int f()
> > {
> >         static i=0;
> >
> >         return i++;
> > }
> >
> > void main()
> > {
> >         cout << f() << f() << f() << endl;
> > }
> >
> > Expected result:
> > 012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!
> >
> > The result is:
> > 210
>
> This is not a bug, but it isn't a feature either. The order of evaluation of
> the three calls to f() is not specified in the standard (though it is noted
> that it is
> not specified) and you really shouldn't try to use such functions with side
> effects
> if the order is relevant. In the end, the problem is the same if you write
>   int i=0;
>   cout << i++ << i++;

Not quite.  In the first case, the functions are guaranteed to act
atomically; even if the order isn't specified, it is specified that
the results will be the three numbers in some order (and not 52, or
a core dump, or a reformatted disk).  In the second case, the behavior
is totally undefined; while I've never heard of a disk actually being
formatted, I can conceive of architectures where a core dump results,
or the system hangs, and I seem to recall reading once about a real
compiler that got a result of 7, or something similar, in a similar
situation.

An example of where you might use a function with side effects several
times in the same expression:

    cout << "Dice throw: "
         << rand() % 6 + 1
         << ", "
         << rand() % 6 + 1
         << endl ;

I'll admit that rand is about the only function I can think of where
this might sometimes be reasonable.

> in which case everyone sees that there may be a problem (when using f(),
> you can only know the problem if you've got the source of f()).
>
> If you want to get a certain order, write
>   cout << f();
>   cout << f();
>   cout << f() << endl;

Correct.  (And I'm really just nit-picking with your posting -- for
all practical purposes, you're right.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


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

cout (stream <<) - Is this a bug?

Is there anyone out there who knows if this is a bug or what's the
problem?????

Problem:

Statement:
cout << "a" << "b" << "c" << endl;

Output:
abc // of course! ;-)


Then one whould expect this statement/code to give the following
result:

int f()
{
 static i=0;

 return i++;
}

void main()
{
 cout << f() << f() << f() << endl;
}

Expected result:
012  // again, of course! - one would say! - BUT HERE'S THE SURPRISE!

The result is:
210


Comments:
If you debug the code, it looks like that the compiler makes the 3
function-calls and placing
there return values on a stack. It then "pops" the values one by one
"sending" them to the (<<)
the stream-operator. Which - of course - provides the "wrong" (at
least that my opinion ;-) )
result/code.

I've test the code on MSVC 5.0 and BC4.52, which both gives the wrong
result (2,1,0).
I've heard that's not a problem with Unix compiler's, but I don't know
if it's true.
If you have the solution or any comments to the problem, please
comment it or e-mail me. THANKS!

 Regards
  Bryske


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