Re: [Mingw-users] [mingw - C/C++] RE: gcc and mingw very minor incompatibility

[Brian H. <bh...@lu...>]

I didn't find the same explicitness in the Dewhurst and Stark C++ ref guide 
on operators,
however, I assumed the poster was using C, since the code looks like C, and 
he didn't
specify whether it was a .cc file, or a .c file.

I disagree that the incrementing of c is a side effect.  I don't see that
spelled out that way in the specification.

I also understand what people are saying about order of evaluation, 
particularly when it
comes to the order of evaluation tricking things up.  However, I don't see 
that being
the case here, and in fact, the first example, where there could be a 
debate, produces
results we expect.  The second example, where there should be NO debate [ c 
= 0; c++; if (c == 0) ]
because clearly ; is a sequencing point.

However, operators which are operators [ relational, equality, or 
arithmetic ] are spelled out
with precedence, and the operators used in this example, are all part of 
that group.

In terms of these operators, they are essentially equivolent grammar wise.

var1 relOP var2 incOP

where elements have the same precedence, order of operation can not be 
assumed.  However, in
this case, there is a difference in precedence.

var incOP will bind before the relOP is compared.

While it is true that C does not specify the order that operands are 
evaluated [ except &&, ||, ?: and , ], that
isn't the issue here.  The operands of the relOP are var1 and var2.  And 
while their order of evaluation is
undetermined, var2 will be incremented before the relOP compares it's two 
operands.

If precedence were not involved here, then
         a case like x = f() + g()
you would have to argue that there is no guarantee that f() will evaluate 
before the +.  Which is not the case.  () has
a higher precedence than +.  What you can not guarantee is whether f() will 
evaluate before g().  But you can guarantee
that the () for both will evaluate before the + operator because of precedence.

The same applies to the example the original poster made.

However, this is all way off topic, as the first test works just fine [ as 
I'd expect ].  It is the second test, in which
evaluation order shouldn't even be an issue, which produces different 
results with the different compilers that
is the posters main concern.




At 05:09 PM 9/13/2004 -0700, SourceForge.net wrote:

>Read and respond to this message at:
>https://sourceforge.net/forum/message.php?msg_id=2757732
>By: aaronwl
>
>The incrementing of c by c++ is called a side effect.  In this case, we're 
>interested
>in whether the side effect will happen before or after equality is evaluated
>(c == c++).
>
>As it were, the C standard permits compilers to handle side effects whenever
>they like, as long as all side effects have are completed before the next 
>sequence
>point.  Sequence points are things like the end of a statement or function 
>calls.
>(See the standard for the full list.)  Most operators are not sequence points,
>and in particular, == isn't, and so the comparison will evaluate differently
>unpredictably.
>
>Since the compiler is given this freedom to execute side affects however it
>likes, it does.  It tries to execute it in a manner that will result in the
>best code, which can vary unpredictably, which is why your results change
>unpredictably.
>
>Aaron W. LaFramboise
>
>
>______________________________________________________________________
>You are receiving this email because you elected to monitor this forum.
>To stop monitoring this forum, login to SourceForge.net and visit:
>https://sourceforge.net/forum/unmonitor.php?forum_id=286529
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM.
>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>MinGW-users mailing list
>Min...@li...
>
>You may change your MinGW Account Options or unsubscribe at:
>https://lists.sourceforge.net/lists/listinfo/mingw-users

+==========================================================+
Brian N. Hawley                 bh...@lu...
Luminex Software, Inc.          http://www.luminex.com
PO Box 5908                     voice: 909-781-4100 x112
Riverside, CA  92517            fax: 909-781-4105
+==========================================================+