Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #23318 > unrolled thread

Precedence Misunderstanding

Back to article view | Back to comp.lang.c

Contents

  Precedence Misunderstanding Charles Richmond <frizzle@aquaporin4.com> - 2012-07-16 23:18 -0500
    Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-16 21:54 -0700
      Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-16 22:13 -0700
        Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-16 22:36 -0700
          Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-17 13:57 +0100
      Re: Precedence Misunderstanding "Charles Richmond" <numerist@aquaporin4.com> - 2012-07-17 13:35 -0500
        Re: Precedence Misunderstanding "io_x" <a@b.c.invalid> - 2012-07-17 20:48 +0200
        Re: Precedence Misunderstanding Robert Wessel <robertwessel2@yahoo.com> - 2012-07-17 13:45 -0500
        Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-17 12:27 -0700
          Re: Precedence Misunderstanding Willem <willem@toad.stack.nl> - 2012-07-17 20:20 +0000
        Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-17 20:34 +0100
          Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-17 12:39 -0700
            Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-17 20:57 +0100
          Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-17 20:48 +0100
            Re: Precedence Misunderstanding Philip Lantz <prl@canterey.us> - 2012-07-17 21:12 -0700
              Re: Precedence Misunderstanding Ike Naar <ike@iceland.freeshell.org> - 2012-07-18 07:14 +0000
                Re: Precedence Misunderstanding "BartC" <bc@freeuk.com> - 2012-07-18 10:11 +0100
                  Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-18 09:18 -0700
                  Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 18:10 +0100
                    Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-18 18:27 +0100
                      Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 18:53 +0100
                        Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-18 21:07 +0100
                  Re: Precedence Misunderstanding Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-19 20:47 +0300
                Re: Precedence Misunderstanding Philip Lantz <prl@canterey.us> - 2012-07-18 23:54 -0700
                  Re: Precedence Misunderstanding Ike Naar <ike@sverige.freeshell.org> - 2012-07-19 07:21 +0000
        Re: Precedence Misunderstanding "BartC" <bc@freeuk.com> - 2012-07-17 20:42 +0100
        Re: Precedence Misunderstanding Willem <willem@toad.stack.nl> - 2012-07-17 20:38 +0000
          Re: Precedence Misunderstanding Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-19 20:54 +0300
            Re: Precedence Misunderstanding Willem <willem@toad.stack.nl> - 2012-07-19 22:02 +0000
        Re: Precedence Misunderstanding pete <pfiland@mindspring.com> - 2012-07-17 22:31 -0400
        Re: Precedence Misunderstanding Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-18 00:35 -0700
      Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-17 22:16 +0100
        Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-17 14:22 -0700
          Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 16:35 +0100
            Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-18 10:03 -0700
              Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 18:32 +0100
                Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-18 10:45 -0700
                  Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 19:29 +0100
                    Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-18 11:45 -0700
                    Re: Precedence Misunderstanding Keith Thompson <kst-u@mib.org> - 2012-07-18 13:26 -0700
                    Re: Precedence Misunderstanding Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-19 00:51 -0700
                Re: Precedence Misunderstanding Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-19 00:11 -0700
    Re: Precedence Misunderstanding Robert Wessel <robertwessel2@yahoo.com> - 2012-07-17 00:05 -0500
    Re: Precedence Misunderstanding Ike Naar <ike@iceland.freeshell.org> - 2012-07-17 07:40 +0000

Page 1 of 3  [1] 2 3  Next page →

#23318 — Precedence Misunderstanding

Consider the following program:

#include  <stdio.h>
#include  <stdlib.h>

int main()
{
    int i = 4, j = 12, k = 41;

    printf("expression is %d + %d * %d\n",k,j,i);
    printf("--> value  is %d\n",k + j * i);
}

When compiled and run, the output was:

expression is 41 + 12 * 4
--> value  is 89

Because the multiply operator has a *higher* precedence than the 
addition operator... the multiply is done first. So the result is 
89, and *not* 212.


Now take the following program:

#include  <stdio.h>
#include  <stdlib.h>

int  callthis();

int main()
{
    int i = 1, j = 1, k = 0;

    printf("expression is %s\n","i || j && k");
    printf("--> value  is %d\n",i || j && k);

    printf("expression is %s\n","i || j && callthis()");
    printf("--> vnext  is %d\n",i || j && callthis());
}

int callthis()
{
    printf("--> The function is called.\n");

    return  1;
}

When compiled and run, the output was:

expression is i || j && k
--> value  is 1
expression is i || j && callthis()
--> vnext  is 1


The point I'm making is:  The Good Book (K&R II) says that 
"logical and" (&&) has a *higher* precedence that "logical or" 
(||).  And that same Good Book says that a series of "logical and" 
and "logical or" operations will occur left to right.

And so it is... left to right evaluation.  But *how* then does the 
"logical and" have a *higher* precedence than "logical or"... when 
this is ignored in the series of AND's and OR's???

(Yes, yes... I know about "short circuit" operators.  But I 
thought this was operator by operator.  In other words, if in the 
"i || j && callthis()", *if* the AND were done first [it's 
*not*]... and if "j" were FALSE, callthis() would *not* be done.

The actual evaluation is "i || j" done first... if "i" is TRUE, 
the the *entire* rest of the expression is short circuited.

Can someone explain how "&&" can have a *higher* precedence than 
"||"... when the series of AND's and OR's are just going to be 
done left to right???

I *thought* I understood C pretty well... guess not.

-- 

numerist at aquaporin4 dot com

[toc] | [next] | [standalone]

#23320

Charles Richmond <frizzle@aquaporin4.com> writes:

> Can someone explain how "&&" can have a *higher* precedence than
> "||"... when the series of AND's and OR's are just going to be done
> left to right???

I think there's a lot of confusion on this point because we
aren't taught about this in our math classes.  That's because
side effects don't exist in math, so order of evaluation doesn't
matter.  Precedence does, but that's a different issue.

Consider 2 * 3 + 4 * 5.  Precedence says that this must be
treated the same as (2 * 3) + (4 * 5).  But once you figure that
out, you have a choice: you can evaluate 2 * 3 first or you can
evaluate 4 * 5 first, because the order doesn't matter.  No one
bothers to say that you have to evaluate left-to-right or even
that you have to evaluate right-to-left, because that would not
change the eventual result in any way.

When side effects come in, the situation changes.  a() + b()
might do something completely different depending on which of a()
or b() you call first.  Extending it to a() + b() * c(), then
precedence comes in.  C doesn't say in what order a(), b(), and
c() are evaluated, but it does say that once they are evaluated,
you have to multiply b() by c(), not by a().

I hope that helps.

[toc] | [prev] | [next] | [standalone]

#23323

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Pfaff <blp@cs.stanford.edu> writes:
>>I think there's a lot of confusion on this point because we
>>aren't taught about this in our math classes.  That's because
>>side effects don't exist in math, so order of evaluation doesn't
>>matter.  Precedence does, but that's a different issue.
>
>   I was taught about associativity already in elementary school IIRC.
>   After all, you need to know whether 2-3-4 is (2-3)-4 or 2-(3-4).

That's just another aspect of precedence.  The evaluation of each
function call in a()-b()-c() isn't any more strictly ordered than
a()+b()*c().

[toc] | [prev] | [next] | [standalone]

#23325

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Pfaff <blp@cs.stanford.edu> writes:
>>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>I was taught about associativity already in elementary school IIRC.
>>>After all, you need to know whether 2-3-4 is (2-3)-4 or 2-(3-4).
>>That's just another aspect of precedence.
>
>   Associativity is not an »aspect of precedence«. Precedence
>   and associativity are treated as two separate concerns.

I may be misusing the term--your evidence seems good to me--but
the point that I was making remains: whether 2-3-4 is (2-3)-4 or
2-(3-4) is a separate issue from the order in which each operand
is evaluated.

[toc] | [prev] | [next] | [standalone]

#23332

Ben Pfaff <blp@cs.stanford.edu> writes:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> Ben Pfaff <blp@cs.stanford.edu> writes:
>>>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>>I was taught about associativity already in elementary school IIRC.
>>>>After all, you need to know whether 2-3-4 is (2-3)-4 or 2-(3-4).
>>>That's just another aspect of precedence.
>>
>>   Associativity is not an »aspect of precedence«. Precedence
>>   and associativity are treated as two separate concerns.
>
> I may be misusing the term--your evidence seems good to me--but
> the point that I was making remains: whether 2-3-4 is (2-3)-4 or
> 2-(3-4) is a separate issue from the order in which each operand
> is evaluated.

In some ways I don't think you are misusing the term, although common
usage has certainly decided that separating precedence and associativity
makes life simpler for most programming languages.  Some parser
generators dispense with this distinction by allow an operator to have
two precedences -- a left precedence and a right precedence.  This
allows associativity to be folded into the concept of precedence.  There
are also languages where you need this concept to understand how to
parse its expressions.  Perl's list operators, for example, have highly
asymmetric left and right precedence so they can't be described using
the common notions of precedence and associativity.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23335

"Ben Pfaff" <blp@cs.stanford.edu> wrote in message 
news:874np7j8br.fsf@blp.benpfaff.org...
> Charles Richmond <frizzle@aquaporin4.com> writes:
>
>> Can someone explain how "&&" can have a *higher* precedence than
>> "||"... when the series of AND's and OR's are just going to be done
>> left to right???
>
> I think there's a lot of confusion on this point because we
> aren't taught about this in our math classes.  That's because
> side effects don't exist in math, so order of evaluation doesn't
> matter.  Precedence does, but that's a different issue.
>
> Consider 2 * 3 + 4 * 5.  Precedence says that this must be
> treated the same as (2 * 3) + (4 * 5).  But once you figure that
> out, you have a choice: you can evaluate 2 * 3 first or you can
> evaluate 4 * 5 first, because the order doesn't matter.  No one
> bothers to say that you have to evaluate left-to-right or even
> that you have to evaluate right-to-left, because that would not
> change the eventual result in any way.
>
> When side effects come in, the situation changes.  a() + b()
> might do something completely different depending on which of a()
> or b() you call first.  Extending it to a() + b() * c(), then
> precedence comes in.  C doesn't say in what order a(), b(), and
> c() are evaluated, but it does say that once they are evaluated,
> you have to multiply b() by c(), not by a().
>

Mr. Pfaff, I *do* understand about "side effects" with expression evaluation 
in programming languages.  I understand *why* short circuiting and 
guaranteeing the order of execution... *can* be helpful at times.

The crux of what I do *not* understand is this:

Can someone explain how "&&" can have a *higher* precedence than
"||"... when any series of AND's and OR's are just going to be
done left to right???

For example, if you have a long series of logical AND's and OR's like this:

    a && b || c || d && x && y || z

How will "&&" having a higher precedence than "||" effect this at all??? 
ISTM that evaluation would be the *same* if "&&" and "||" were of equal 
precedence.

Create any series of AND's and OR's you want, and please show me how the 
precedence of "&&'" and "||" will make any difference under the current C 
standard.

Also ISTM that in the above expression, it will *not* matter if one adds 
parentheses around any operator/operand pair or grouping.  The result seems 
to be the same.  Please show me where I'm wrong.

I can *not* understand how "&&" can have a higher precedence than "||"... 
when it seems to make *no* difference in *any* expression I've seen.

--

numerist at aquaporin4 dot com

[toc] | [prev] | [next] | [standalone]

#23336

"Charles Richmond" <numerist@aquaporin4.com> ha scritto nel messaggio 
news:ju4ba5$lso$1@dont-email.me...

you and i have to use () where not rememeber precedence...

[toc] | [prev] | [next] | [standalone]

#23337

On Tue, 17 Jul 2012 13:35:43 -0500, "Charles Richmond"
<numerist@aquaporin4.com> wrote:

>"Ben Pfaff" <blp@cs.stanford.edu> wrote in message 
>news:874np7j8br.fsf@blp.benpfaff.org...
>> Charles Richmond <frizzle@aquaporin4.com> writes:
>>
>>> Can someone explain how "&&" can have a *higher* precedence than
>>> "||"... when the series of AND's and OR's are just going to be done
>>> left to right???
>>
>> I think there's a lot of confusion on this point because we
>> aren't taught about this in our math classes.  That's because
>> side effects don't exist in math, so order of evaluation doesn't
>> matter.  Precedence does, but that's a different issue.
>>
>> Consider 2 * 3 + 4 * 5.  Precedence says that this must be
>> treated the same as (2 * 3) + (4 * 5).  But once you figure that
>> out, you have a choice: you can evaluate 2 * 3 first or you can
>> evaluate 4 * 5 first, because the order doesn't matter.  No one
>> bothers to say that you have to evaluate left-to-right or even
>> that you have to evaluate right-to-left, because that would not
>> change the eventual result in any way.
>>
>> When side effects come in, the situation changes.  a() + b()
>> might do something completely different depending on which of a()
>> or b() you call first.  Extending it to a() + b() * c(), then
>> precedence comes in.  C doesn't say in what order a(), b(), and
>> c() are evaluated, but it does say that once they are evaluated,
>> you have to multiply b() by c(), not by a().
>>
>
>Mr. Pfaff, I *do* understand about "side effects" with expression evaluation 
>in programming languages.  I understand *why* short circuiting and 
>guaranteeing the order of execution... *can* be helpful at times.
>
>The crux of what I do *not* understand is this:
>
>Can someone explain how "&&" can have a *higher* precedence than
>"||"... when any series of AND's and OR's are just going to be
>done left to right???
>
>For example, if you have a long series of logical AND's and OR's like this:
>
>    a && b || c || d && x && y || z
>
>How will "&&" having a higher precedence than "||" effect this at all??? 
>ISTM that evaluation would be the *same* if "&&" and "||" were of equal 
>precedence.
>
>Create any series of AND's and OR's you want, and please show me how the 
>precedence of "&&'" and "||" will make any difference under the current C 
>standard.
>
>Also ISTM that in the above expression, it will *not* matter if one adds 
>parentheses around any operator/operand pair or grouping.  The result seems 
>to be the same.  Please show me where I'm wrong.
>
>I can *not* understand how "&&" can have a higher precedence than "||"... 
>when it seems to make *no* difference in *any* expression I've seen.


Assuming a=1 and c=0:

a || (b && c)

is clearly different than:

(a || b) && c

The first will always return one, the second, zero.

Unless I'm completely misunderstanding your question.

[toc] | [prev] | [next] | [standalone]

#23339

"Charles Richmond" <numerist@aquaporin4.com> writes:

> "Ben Pfaff" <blp@cs.stanford.edu> wrote in message
> For example, if you have a long series of logical AND's and OR's like this:
>
>    a && b || c || d && x && y || z
>
> How will "&&" having a higher precedence than "||" effect this at
> all??? ISTM that evaluation would be the *same* if "&&" and "||" were
> of equal precedence.

Precedence doesn't affect the order of evaluation of the
terminals in this case but it affects the result.  Your
expression is equivalent to:
        (a && b) || c || (d && x && y) || z
which could have a different value from:
        a && (b || c || d) && x && (y || z)
even though in each case the terminals are always evaluated
left-to-right (a fact that I hadn't noticed before) if they are
evaluated at all.

[toc] | [prev] | [next] | [standalone]

#23347

Ben Pfaff wrote:
) "Charles Richmond" <numerist@aquaporin4.com> writes:
)
)> "Ben Pfaff" <blp@cs.stanford.edu> wrote in message
)> For example, if you have a long series of logical AND's and OR's like this:
)>
)>    a && b || c || d && x && y || z
)>
)> How will "&&" having a higher precedence than "||" effect this at
)> all??? ISTM that evaluation would be the *same* if "&&" and "||" were
)> of equal precedence.
)
) Precedence doesn't affect the order of evaluation of the
) terminals in this case but it affects the result.  Your
) expression is equivalent to:
)         (a && b) || c || (d && x && y) || z
) which could have a different value from:
)         a && (b || c || d) && x && (y || z)
) even though in each case the terminals are always evaluated
) left-to-right (a fact that I hadn't noticed before) if they are
) evaluated at all.

Yes.  But some terminals could be skipped because of short-circuiting.
And different ones could be skipped if the parentheses were different.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#23340

"Charles Richmond" <numerist@aquaporin4.com> writes:
<snip>
> Can someone explain how "&&" can have a *higher* precedence than
> "||"... when any series of AND's and OR's are just going to be
> done left to right???

No, because it's not true.  A sequence of &&s is done left to right, and
a sequence of ||s is done left to right, but when &&s and ||s are mixed
the precedence matters.

> For example, if you have a long series of logical AND's and OR's like this:
>
>    a && b || c || d && x && y || z
>
> How will "&&" having a higher precedence than "||" effect this at
> all??? ISTM that evaluation would be the *same* if "&&" and "||" were
> of equal precedence.
> Create any series of AND's and OR's you want, and please show me how
> the precedence of "&&'" and "||" will make any difference under the
> current C standard.

Lets take a simple example

  a || b && c

means

  a || (b && c)

but if && and || had equal precedence it would mean

  (a || b) && c

These two expressions are not the same -- the precedence makes a
difference.

> Also ISTM that in the above expression, it will *not* matter if one
> adds parentheses around any operator/operand pair or grouping.  The
> result seems to be the same.  Please show me where I'm wrong.

It's a messy example but

    a && b || c || d && x && y || z

means

    ((((a && b) || c) || ((d && x) && y))) || z

so it is true if z is non-zero regardless of the values of the other
variables.  Add parentheses like this:

    a && (b || c || d) && x && (y || z)

and your get quite another expression.  For example, a, x and one of b,
c or d must also be non-zero for it to be true.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23342

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> "Charles Richmond" <numerist@aquaporin4.com> writes:
> <snip>
>> Can someone explain how "&&" can have a *higher* precedence than
>> "||"... when any series of AND's and OR's are just going to be
>> done left to right???
>
> No, because it's not true.  A sequence of &&s is done left to right, and
> a sequence of ||s is done left to right, but when &&s and ||s are mixed
> the precedence matters.

[...]

> Lets take a simple example
>
>   a || b && c
>
> means
>
>   a || (b && c)
>
> but if && and || had equal precedence it would mean
>
>   (a || b) && c
>
> These two expressions are not the same -- the precedence makes a
> difference.

I think Charles is saying that, regardless of precedence, a is
evaluated before b and b is evaluated before c.  That's correct,
I think.

[toc] | [prev] | [next] | [standalone]

#23345

Ben Pfaff <blp@cs.stanford.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> "Charles Richmond" <numerist@aquaporin4.com> writes:
>> <snip>
>>> Can someone explain how "&&" can have a *higher* precedence than
>>> "||"... when any series of AND's and OR's are just going to be
>>> done left to right???
>>
>> No, because it's not true.  A sequence of &&s is done left to right, and
>> a sequence of ||s is done left to right, but when &&s and ||s are mixed
>> the precedence matters.
>
> [...]
>
>> Lets take a simple example
>>
>>   a || b && c
>>
>> means
>>
>>   a || (b && c)
>>
>> but if && and || had equal precedence it would mean
>>
>>   (a || b) && c
>>
>> These two expressions are not the same -- the precedence makes a
>> difference.
>
> I think Charles is saying that, regardless of precedence, a is
> evaluated before b and b is evaluated before c.  That's correct,
> I think.

Yes, it is, but he seems to think that that means either that precedence
has no effect, or that && and || must have the same precedence.

My answer should really have unpicked these three things: yes you get
left-to-right evaluation (though it can stop short, of course); yes &&
does have higher precedence than || (simply by definition of the
language); and yes the precedence makes a difference to the expression.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23344

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> "Charles Richmond" <numerist@aquaporin4.com> writes:
> <snip>
>> Can someone explain how "&&" can have a *higher* precedence than
>> "||"... when any series of AND's and OR's are just going to be
>> done left to right???
>
> No, because it's not true.  A sequence of &&s is done left to right, and
> a sequence of ||s is done left to right, but when &&s and ||s are mixed
> the precedence matters.

...but this could be expressed more clearly: the precedence matters, but
an operand that is further to the right is never evaluated before one to
its left.

This, by the way, is specific to the short-circuit nature of && and ||,
and of the fact that the left-hand operand is always evaluated first.
The right-hand operand may not be evaluated at all, so the notion of a
strict left-to-right evaluation is not exactly true -- the evaluation
can skip one or more operands.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#23354

Ben Bacarisse wrote:
[Referring to an expression containing only && and || operators]
> an operand that is further to the right is never evaluated before one
> to its left.

Except when one to its left doesn't need to be evaluated.

For example, in
   (a || b) && c
with a = 1, a is evaluated, b is not evaluated, and c is evaluated.

The same thing happens in
    a && b || c
with a = 0.

[toc] | [prev] | [next] | [standalone]

#23355

On 2012-07-18, Philip Lantz <prl@canterey.us> wrote:
> Ben Bacarisse wrote:
> [Referring to an expression containing only && and || operators]
>> an operand that is further to the right is never evaluated before one
>> to its left.
>
> Except when one to its left doesn't need to be evaluated.
>
> For example, in
>    (a || b) && c
> with a = 1, a is evaluated, b is not evaluated, and c is evaluated.

It's not a counterexample to what Ben said.
Even in your example, no operand is evaluated before one to its left.

[toc] | [prev] | [next] | [standalone]

#23359

"Ike Naar" <ike@iceland.freeshell.org> wrote in message 
news:slrn3vfsk0coir.5s0.ike@iceland.freeshell.org...
> On 2012-07-18, Philip Lantz <prl@canterey.us> wrote:
>> Ben Bacarisse wrote:
>> [Referring to an expression containing only && and || operators]
>>> an operand that is further to the right is never evaluated before one
>>> to its left.
>>
>> Except when one to its left doesn't need to be evaluated.
>>
>> For example, in
>>    (a || b) && c
>> with a = 1, a is evaluated, b is not evaluated, and c is evaluated.
>
> It's not a counterexample to what Ben said.
> Even in your example, no operand is evaluated before one to its left.

How about:

 a && 0

or:

 a || 1

a needn't be evaluated; but it is.

-- 
Bartc  

[toc] | [prev] | [next] | [standalone]

#23362

"BartC" <bc@freeuk.com> writes:

> "Ike Naar" <ike@iceland.freeshell.org> wrote in message
> news:slrn3vfsk0coir.5s0.ike@iceland.freeshell.org...
>> On 2012-07-18, Philip Lantz <prl@canterey.us> wrote:
>>> Ben Bacarisse wrote:
>>> [Referring to an expression containing only && and || operators]
>>>> an operand that is further to the right is never evaluated before one
>>>> to its left.
>>>
>>> Except when one to its left doesn't need to be evaluated.
>>>
>>> For example, in
>>>    (a || b) && c
>>> with a = 1, a is evaluated, b is not evaluated, and c is evaluated.
>>
>> It's not a counterexample to what Ben said.
>> Even in your example, no operand is evaluated before one to its left.
>
> How about:
>
> a && 0
>
> or:
>
> a || 1
>
> a needn't be evaluated; but it is.

"needs to be evaluated" must be interpreted according to C's
rules, of course.

[toc] | [prev] | [next] | [standalone]

#23364

BartC wrote:

> How about:
> 
> a && 0
> 
> or:
> 
> a || 1
> 
> a needn't be evaluated; but it is.

According to the C standard, it is and it should.  The && operator 
guarantees left-to-right evaluation.  Therefore, if that expression is 
supposed to be C then a needs to be evaluated. 


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#23365

Rui Maciel <rui.maciel@gmail.com> writes:

> BartC wrote:
>
>> How about:
>> 
>> a && 0
>> 
>> or:
>> 
>> a || 1
>> 
>> a needn't be evaluated; but it is.
>
> According to the C standard, it is and it should.  The && operator 
> guarantees left-to-right evaluation.  Therefore, if that expression is 
> supposed to be C then a needs to be evaluated. 

That's true as far as the "abstract machine" is concerned: i.e. the
compiler must act *as if* the 'a' is evaluated, but unless 'a' is
volatile, I'd expect a compiler to optimise it away.

(It's possible that BartC wrote 'a' as a placeholder for a general C
sub-expression in which case the answer depends on the details and your
comment is pretty much the end of the matter.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web