Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > C/C++ Ambiguity in Order of Evaluation

Reply
Thread Tools

C/C++ Ambiguity in Order of Evaluation

 
 
Richard Bos
Guest
Posts: n/a
 
      06-21-2007
Rasjid <(E-Mail Removed)> wrote:

> > "Except as indicated by the syntax or otherwise specified later
> > (for the function-call operator () , && , || , ?: , and comma
> > operators), the order of evaluation of subexpressions and the order in
> > which side effects take place are both unspecified."

>
> This is from msdn2.microsoft, under C Reference Manual:-
> "Precedence and Order of Evaluation
>
> The precedence and associativity of C operators affect the grouping
> and evaluation of operands in expressions.


Unless this is a MSVC++##4.0 manual, and not a C Reference Manual as
such, that is simply a lie.

> I am not sure if anyone take issue with the paragraph.


Oh, I should hope so. It's wrong. Of course, it's Microsoft, so no
surprise there; they always insist that their way is the only way, and
industry standards exist so they can break them.

> > > So after a long long time my confusion is resolved, but only by
> > > throwing away the official document (that seems only to confuse) -
> > > that's bad.

> >
> > No, your official C++ document stopped being official almost a decade
> > ago. It was replaced by ISO/IEC 14882:1998 (which, I believe, has since
> > been replaced by an update). Here in comp.lang.c we use ISO/IEC
> > 9899:1990 or ISO/IEC 9899:1999, depending on who you talk to.

>
> I some parts or niches of the world, information takes 40 years to get
> through.


Tough cookies - 40 years ago it was 1967, and C wasn't invented yet.

> Had I known it is undefined, I'll do this/rather it should have been
> this :-
> If ( exprA && ((u = bitboard1 | bitboard2) , (w = (u - ((u & -u) <<
> 1)))) ){


*Brrrrr*

Vade retro, Perlhackere!

Richard
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      06-21-2007
CBFalconer said:

> Rasjid wrote:
>>

> ... snip ...
>>
>> The 4 replies basically is in agreement and my main comments is
>> in my reply to Richard Heathfield.
>>
>> I think my problem is resolved. It seems I was in some way misled.
>> Had there be no mentioned of order of evaluations etc, then
>> everyone would have been careful when trying such as:-
>> a = b + (b = 1);

>
> If you are going to post here regularly you need to learn not to
> top-post, and to limit your line lengths (under 72 is good, 67 is
> better).


Chuck, if you are going to post content-free material, could you please
adjust the subject line, like Default User does? That way, I can filter
it out.

Thanks.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      06-21-2007
Rasjid wrote:
>

.... snip ...
>
> This is from msdn2.microsoft, under C Reference Manual:-
> "Precedence and Order of Evaluation
>
> The precedence and associativity of C operators affect the grouping
> and evaluation of operands in expressions. An operator's precedence
> is meaningful only if other operators with higher or lower
> precedence are present. Expressions with higher-precedence
> operators are evaluated first. Precedence can also be described by
> the word "binding." Operators with a higher precedence are said to
> have tighter binding. "


Around here we tend to use the official C standard, rather than MS
mis-interpretations.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      06-21-2007
Rasjid wrote:
> On Jun 21, 10:27 am, CBFalconer <(E-Mail Removed)> wrote:
>
>> Please do not top-post. Your answer belongs after (or intermixed
>> with) the quoted material to which you reply, after snipping all
>> irrelevant material. See the following links:

>
> Thanks, I test if it works. Why no preview for reply?


I have no idea. Try a real newsreader and server rather than the
poor google interface.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
bjarne
Guest
Posts: n/a
 
      06-21-2007
On Jun 20, 2:23 pm, Richard Heathfield <(E-Mail Removed)> wrote:
....
>
> >> >>From the reference manual I have :-
> >> > 1) "The order of evaluation of subexpressions is determined by the
> >> > precedence and grouping of operators."

> > It's from BjarneStroustrupC++ ..., Reference Manual of C++ as of May
> > 1991.

>
> "The order of evaluation of subexpressions within an expression is
> undefined." - Bjarne Stroustrup, "The C++ Programming Language",
> Special Edition, January 2000.
>
> Mr Stroustrup appears to disagree with Mr Stroustrup. Here in
> comp.lang.c we cannot possibly countenance judging between the opinions
> of these two C++ masters, so I must refer you to comp.lang.c++, where
> you may well find that either Mr Stroustrup or Mr Stroustrup will be
> able to clarify.




> (To be belatedly fair to Bjarne Stroustrup, something rather important
> and dramatic happened to C++ between 1991 and 1998.)


Indeed, but the standardization only clarified that part of the text,
rather than changing the rules. The full quote is/was

The order of evaluation of subexpressions is determined by the
precedence and grouping of
the operators. The usual mathematical rules for associativity and
commutativity of operators
may be applied only where the operators really are associative and
commutative. Except
where noted, the order of evaluation of operands of individual
operators is undefined. In
particular, if a value is modified twice in an expression, the
result of the expression is
undefined except where an ordering is guaranteed by the operators
involved. For example:
i = v [i++; ] // the value of 'i8 is undefined
i-7, i++i+,+ ; // 'it becomes 9

I was (I think and rather unsuccessfully) trying to distinguish
between the effect of the grouping and precedence rules (as in (x*y)/z
v.s. x*(y/z)) on the meaning of an expression and the order of
evaluations rules.

Except where noted, the order of evaluation of operands of
individual operators is undefined.

Makes clear that there was no C/C++ incompatibility in this case
("except where noted" refers to the text for ||, &&, and comma). I
don't recall this as a significant problem for users and none for
implementers.

It is always hazardous to cut part of a paragraph out of context.

-- Bjarne Stroustrup; http://www.research.att.com/~bs


 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      06-21-2007
On 21 Jun 2007 10:10:40 GMT, Charles Bailey
<(E-Mail Removed)> wrote:

>On 2007-06-21, Barry Schwarz <(E-Mail Removed)> wrote:
>> On Wed, 20 Jun 2007 22:53:16 -0700, Rasjid <(E-Mail Removed)>
>> wrote:
>>>Maybe this is better:-
>>>"Expressions with higher-precedence operators are evaluated first
>>>assuming all relevant operands have been evaluated as they may be
>>>evaluated in any order."

>>
>> Still not true. Consider
>> a = b * c + d + e;
>> Multiplication is the highest precedence but it is still legal for d+e
>> to be evaluated prior to a*b. If d+e is a common expression, it may
>> have been evaluated in a previous statement and not recomputed here.
>>

>
>I think that this is misleading. d+e should not be evaluated at all.
>
>additive-expression:
> multiplicative-expression
> additive-expression + multiplicative-expression
> additive-expression - multiplicative-expression
>
>d+e is an additive expression, not a multiplicative-expression so
>can't form the right hand side of an additive expression.


Would it make you happier if the code were written
a = d + e + b * c;

The point remains unchanged. There is no guarantee that b*c will be
evaluated first, which is what the OP wanted to claim.


Remove del for email
 
Reply With Quote
 
Charles Bailey
Guest
Posts: n/a
 
      06-21-2007
On 2007-06-21, Barry Schwarz <(E-Mail Removed)> wrote:
> On 21 Jun 2007 10:10:40 GMT, Charles Bailey
><(E-Mail Removed)> wrote:
>>
>>I think that this is misleading. d+e should not be evaluated at all.
>>
>>additive-expression:
>> multiplicative-expression
>> additive-expression + multiplicative-expression
>> additive-expression - multiplicative-expression
>>
>>d+e is an additive expression, not a multiplicative-expression so
>>can't form the right hand side of an additive expression.

>
> Would it make you happier if the code were written
> a = d + e + b * c;
>
> The point remains unchanged. There is no guarantee that b*c will be
> evaluated first, which is what the OP wanted to claim.
>


Yes, in that I think that this is a much better example. Both d + e
and b * c are constituent sub-expressions of the overall expression
and so both do have to be evaluated. There is no reason, either in
the C standard or - as succinctly put in a previous thread on this
subject - in reality, for either to be evaluated before the other.
 
Reply With Quote
 
Rasjid
Guest
Posts: n/a
 
      06-21-2007
On Jun 21, 6:24 pm, (E-Mail Removed) (Richard Bos) wrote:

> > This is from msdn2.microsoft, under C Reference Manual:-
> > "Precedence and Order of Evaluation

>
> > The precedence and associativity of C operators affect the grouping
> > and evaluation of operands in expressions.

>
> Unless this is a MSVC++##4.0 manual, and not a C Reference Manual as
> such, that is simply a lie.
>
> > I am not sure if anyone take issue with the paragraph.

>
> Oh, I should hope so. It's wrong. Of course, it's Microsoft, so no
> surprise there; they always insist that their way is the only way, and
> industry standards exist so they can break them.

I think I learn something , that little knowledge hurts. There is C
and there is C.
We have to know what we're reading.

BTW, I think hordes of DIY programmers ( like me) out there think in a
* b + c, that things got multiplied before added, other things
ignored!

Thanks,
Rasjid


 
Reply With Quote
 
Rasjid
Guest
Posts: n/a
 
      06-21-2007
On Jun 21, 9:48 pm, bjarne <(E-Mail Removed)> wrote:
....
> > (To be belatedly fair to Bjarne Stroustrup, something rather important
> > and dramatic happened to C++ between 1991 and 1998.)

>
> Indeed, but the standardization only clarified that part of the text,
> rather than changing the rules. The full quote is/was
>
> The order of evaluation of subexpressions is determined by the
> precedence and grouping of the operators. The usual ...


A reference manual that implements a language standard should be as
simple
as is possible. If anything is discovered that is superfluous it
should be eliminated.

Order of evaluation is a critical matter in the execution of codes and
may be a complicated issue. There is order of application of operators
on operands as well as order of evaluation of operands. What have been
written so far here seem to suggest there is almost no connection
between precedence of operators and order of evaluation of
subexpressions. I asked for any instance where there is a need to
invoke operator precedence/order rule to resolve things and no one
seem to be able to provide a single example. So it seems any mention
of any connection of precedence of operators with order of evaluation
serves no purpose at all and only causes confusion to unsuspecting
users (potentially many). If the said connection is actually needed in
the C standard, it may be for very rare instances which may be better
settled in other manner that do not cause confusion.

Rasjid


 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      06-21-2007

"Rasjid" <(E-Mail Removed)> ha scritto nel messaggio news:(E-Mail Removed) oups.com...
> On Jun 21, 9:48 pm, bjarne <(E-Mail Removed)> wrote:
> ...
>> > (To be belatedly fair to Bjarne Stroustrup, something rather important
>> > and dramatic happened to C++ between 1991 and 1998.)

>>
>> Indeed, but the standardization only clarified that part of the text,
>> rather than changing the rules. The full quote is/was
>>
>> The order of evaluation of subexpressions is determined by the
>> precedence and grouping of the operators. The usual ...

>
> A reference manual that implements a language standard should be as
> simple
> as is possible. If anything is discovered that is superfluous it
> should be eliminated.
>
> Order of evaluation is a critical matter in the execution of codes and
> may be a complicated issue. There is order of application of operators
> on operands as well as order of evaluation of operands. What have been
> written so far here seem to suggest there is almost no connection
> between precedence of operators and order of evaluation of
> subexpressions. I asked for any instance where there is a need to
> invoke operator precedence/order rule to resolve things and no one
> seem to be able to provide a single example. So it seems any mention
> of any connection of precedence of operators with order of evaluation
> serves no purpose at all and only causes confusion to unsuspecting
> users (potentially many). If the said connection is actually needed in
> the C standard, it may be for very rare instances which may be better
> settled in other manner that do not cause confusion.


a = b * c;

a will (of course) be assigned after both b and c are evaluated.
f(a(x) + b(y));

x will have to be evaluated before a(), y before b(), and f() after
both a and b, of course. But any of the orders
x, y, a(), b(), f() or
x, y, b(), a(), f() or
x, a(), y, b(), f() or
y, x, a(), b(), f() or
y, x, b(), a(), f() or
y, b(), x, a(), f() (am I missing some?) are allowed.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
evaluation order Nan Li Java 11 11-15-2005 03:26 PM
[EVALUATION] - E03 - jamLang Evaluation Case Applied to Python Ilias Lazaridis Python 2 04-24-2005 05:29 PM
[EVALUATION] - E04 - jamPersist Evaluation Case Applied to Ruby Ilias Lazaridis Ruby 18 04-09-2005 04:45 PM
[EVALUATION] - E03 - jamLang Evaluation Case Applied to Ruby Ilias Lazaridis Ruby 74 04-04-2005 05:29 PM
Evaluation order for a=b Xavier Decoret C++ 1 07-03-2003 07:09 PM



Advertisments