In article <Frode.Nilsen-0907021146080001@morgan.mison.no>,
Frode.Nilsen@mison.no says...
> But when you mix the operators as in ( 1 & 0 | 1 ) there is a need for a
> rule to define the outcome of this.
>
> 5    4 "Except where noted, the order of evaluation of operands of
> individual operators and subexpressions of individual expressions, and the
> order in which side effects take place is undefined."
>
> A footnote to this paragraph states "The precedence of operators is not
> directly specified, but it can be derived from the syntax."
>
> I can't find any other definition of precedence, therefore my original "claim".
>
> If someone could clarify this to me, it would be appreciated.
[note to moderators - I posted a response to this already, but I never
got an automated acknowledgement of receipt. My ISP may be acting up
again, so I'm cc'ing this response to the email submission address -
hopefully there will be no duplicates]

As the footnote says, the precedence "can be derived from the syntax."
Suppose you have an expression:

  a | b & c

The syntax is defined by the grammar, so looking at the grammar for
bitwise | and bitwise & we see:

and-expression:
  equality-expression
  and-expression & equality-expression

exclusive-or-expression:
  and-expression
  exclusive-or-expression ^ and-expression

inclusive-or-expression:
  exclusive-or-expression
  inclusive-or-expression | exclusive-or-expression

Let's parse this left-to-right, starting with the bitor. The expression
"a | b & c" contains the vertical bar, so this allows the second line to
apply. The expression is: an inclusive-or-expression "a" followed by the
token vertical bar "|" followed by an exclusive-or-expression.

Before the compiler can perform the bitwise or operation, though, it has
to determine whether the exclusive-or-expression is "b" or "b & c".

If the compiler chooses "b" as the exclusive-or-expression, then that
will result in:

inclusive-or-expression "a | b" followed by token "&" followed by
equality-expression "c" (from the definition of and-expression)

Looking at the grammar, though, we see that the token "&" must be
preceded by an and-expression. The expression "a | b" cannot be
interpreted as an and-expression, so if the right side of the inclusive-
or-expression were "b" then the program would be syntactically invalid.

That leaves us with "b & c" as a candidate for the exclusive-or-
expression.

Looking at the grammar for exclusive-or-expression, we see that it can
consist of an and-expression - "b & c" is definitely an and-expression.

So, the original expression "a | b & c " will be parsed as:

inclusive-or-expression "a" followed by token "|" followed by exclusive-
or-expression "b & c". Now, "b & c" is not something that can be
directly applied to the bitwise operator, so the compiler has to resolve
what that evaluates to and _then_ apply the bitwise operator.

The resulting sequence of operations is:
- bitwise AND
- bitwise OR

There can be no other sequence, and still obey the syntactic rules laid
out in the grammar.

As an exercise, you might want to parse out the reverse order: a & b | c
and then move on to a more complex expression, such as a | b & c | d.
And then add parentheses: a | b & (c | d)

You'll note, by the way, that the precedence also matches the order of
clauses within the standard, i.e. anything defined in 5.1 has the
highest precedence, and 5.19 has the lowest.

--
Jim

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Frode.Nilsen@mison.no wrote:
>
> > > What is the rationale for not having any defined grouping order for
> > > bitwise operators ?
> > >=20
> > > e.g. 1 & 0 |=A01 -> undefined result
> > >=20
> > > This is a source for subtle bugs, if it doesn't pay of in other areas, =
> > why
> > > is i like this ?
> > >=20

> ? There are no grouping defined for the bitwise operators 5.11 - 5.13,
> because e.g. A & B & C can be aritmeticaly computed in any order and give
> identical results.
by grouping do you mean associativity or precedence or something else?

>
> But when you mix the operators as in ( 1 & 0 | 1 ) there is a need for a
> rule to define the outcome of this.
the grammar defines what this is. it is the same as ((1 & 0) | 1)


> I can't find any other definition of precedence, therefore my original "claim".
AFAICT you claim that
 1 & 0 | 1 -> undefined result
which is false. 5.11 & 5.13 give a parse for it.

nathan
--
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
           The voices in my head told me to say this
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Frode.Nilsen@mison.no wrote
> ? There are no grouping defined for the bitwise operators 5.11 - 5.13,
> because e.g. A & B & C can be aritmeticaly computed in any order and give
> identical results.

Okay.

> But when you mix the operators as in ( 1 & 0 | 1 ) there is a need for a
> rule to define the outcome of this.

> 5    4 "Except where noted, the order of evaluation of operands of
> individual operators and subexpressions of individual expressions, and the
> order in which side effects take place is undefined."

The result of ((1&0) | 1) equals the result of (1 & (0|1)) -- it's 1
in either case.

As at least two people have pointed out, the rules of precedence make
the expression (1 & 0 | 1) equivalent to ((1&0) | 1). I think you're
still confusing precedence with "order of evaluation." Order of
evaluation means that in this expression:
    result = always1() & always0() | always1b();
In this expression, always0, always1, and always1b can be called in ANY
order. The compiler could choose to call all three of them before performing
any of the bitwise operators. Or, it could call always0 and always1 and
AND the result before it bothered to call always1b. Even more combinations
are possible.

Similarly, in this expression:
    a = always1() + always4() / always2();
You don't know what order these will be called in. The order of precedence
says that the division will involve the results of always4() and always2().
This doesn't mean that the compiler has to call those two functions first,
though. It might have evaluated always1(), even though it has to do the
division before the addition.

HTH

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:

> In article <ag4nrk$ihn$1@eeyore.INS.cwru.edu>, Ken Alverson
> <Ken@Alverson.com> writes
>
>> <xleobx@qmailcomq.com> wrote in message
>> news:8u6V8.13028$T_.272873@iad-read.news.verio.net...
>>
>>>
>>> This immediately prompts the question a la "C++0x wish list": why isn't
>>> there a keyword (or a creative reuse of an existing keyword) that would
>>> allow the user to tell the compiler that f() has no side-effects
>>> (or, rather, that f() should be treated as having no side-effects)?


    The no-side-effects property is sometimes useful, but
there are others that are more useful.  Consider

 "pure" - function is a pure function; output depends
 only on the input arguments and there are no outputs
 other than the returned value.  The compiler may
 thus apply common subexpression elimination, movement,
 and hoisting out of loops to calls of this function.
 Most of the math functions qualify, so this is quite
 useful in numeric code.  FORTRAN knows that its built-in math
 library functions are pure, but C++ does not.

 "no_side_effects" - function does not affect anything
 other than its returned value, but may have hidden inputs.
 Short-cut evaluation need not evaluate this function.

There are other useful properties, and the pre-Java work on
Spring explored this area.  This is a fruitful line of research.
Both functions and arguments can have useful attributes that
restrict what can be done with them.  For example, whether
a passed pointer can be deleted might be specified.

      John Nagle
      Animats



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

xleobx@qmailcomq.com wrote:
>
> Alexander Terekhov <terekhov@web.de> wrote:
>
> > PMFJI... I personally don't care much about "no-side-effect"
> > ["yes-side-effect"], but what I really, REALLY need is this:
>
> >                  >>"async-cancel-safe"<<
>
> > Every library routine should specify whether or not it is
> > async-cancel safe so that programmers know which routines
> > can be called from code that is asynchronously cancelable.
> >                                                        --
> >                          POSIX:'Part B: System Interfaces'
>
> So it is a QoI issue

Nah, to me, it is a 'const safety'-like issue.

> (the compiler will be able to issue a warning),

Error [async-cancel scope -- everything is "async-cancel-safe"
inside it with cancel-type set to PTHREAD_CANCEL_ASYNCHRONOUS].

http://groups.google.com/groups?selm=3D0A11E8.FFEBDB14%40web.de
(Subject: Re: cancelling one thread from inside another one)

> but specifying the attribute will not result in an improvement in efficiency,

It will result in 'almost safe' [much less dangerous] use of
async. cancel -- and that's probably more efficient [and less
annoying for sure] than e.g. pthread_testcancel() in some loop.

> unlike "no-side-effect". Actually, specifying idempotent routines (with
> side-effect) might help too.

Maybe; don't know.

regards,
alexander.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 2 Jul 2002 8:46:52 -0700, Frode.Nilsen@mison.no wrote
(in message <Frode.Nilsen-0207020956050001@morgan.mison.no>):

> What is the rationale for not having any defined grouping order for
> bitwise operators ?
>=20
> e.g. 1 & 0 |=A01 -> undefined result
>=20
> This is a source for subtle bugs, if it doesn't pay of in other areas, =
why
> is i like this ?
>=20

It's the computation order that's undefined, not the grouping.  The
expression
    f() & g() | h()
is equivalent to
    (f() & g()) | h()
because bitwise AND has higher precedence than bitwise inclusive OR.
However, the functions may be called in any order. =20

--=20
Derek Ledbetter
derekledbetter@mindspring.com
"Life's short and hard like a body-building elf."


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <01HW.B94EA08D009C35DE185241D0@news.mindspring.com>, Derek
Ledbetter <derekledbetter@mindspring.com> wrote:

> On Tue, 2 Jul 2002 8:46:52 -0700, Frode.Nilsen@mison.no wrote
> (in message <Frode.Nilsen-0207020956050001@morgan.mison.no>):
>
> > What is the rationale for not having any defined grouping order for
> > bitwise operators ?
> >=20
> > e.g. 1 & 0 |=A01 -> undefined result
> >=20
> > This is a source for subtle bugs, if it doesn't pay of in other areas, =
> why
> > is i like this ?
> >=20
>
> It's the computation order that's undefined, not the grouping.  The
> expression
>     f() & g() | h()
> is equivalent to
>     (f() & g()) | h()
> because bitwise AND has higher precedence than bitwise inclusive OR.
> However, the functions may be called in any order. =20
>

? There are no grouping defined for the bitwise operators 5.11 - 5.13,
because e.g. A & B & C can be aritmeticaly computed in any order and give
identical results.

But when you mix the operators as in ( 1 & 0 | 1 ) there is a need for a
rule to define the outcome of this.

5    4 "Except where noted, the order of evaluation of operands of
individual operators and subexpressions of individual expressions, and the
order in which side effects take place is undefined."

A footnote to this paragraph states "The precedence of operators is not
directly specified, but it can be derived from the syntax."

I can't find any other definition of precedence, therefore my original "claim".

If someone could clarify this to me, it would be appreciated.


sincerely
frode

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Alexander Terekhov <terekhov@web.de> wrote:

>> So it is a QoI issue

> Nah, to me, it is a 'const safety'-like issue.

>> (the compiler will be able to issue a warning),

> Error [async-cancel scope -- everything is "async-cancel-safe"
> inside it with cancel-type set to PTHREAD_CANCEL_ASYNCHRONOUS].

While I'm not disagreeing with the utility of the check,
from a practical standpoint, for it to be an error, too many new notions
must be brought into the language. "Const-ness", OTOH, is already there.

> http://groups.google.com/groups?selm=3D0A11E8.FFEBDB14%40web.de
> (Subject: Re: cancelling one thread from inside another one)

>> but specifying the attribute will not result in an improvement in efficiency,

> It will result in 'almost safe' [much less dangerous] use of
> async. cancel -- and that's probably more efficient [and less
> annoying for sure] than e.g. pthread_testcancel() in some loop.

Why not make

printf ("%d %s", 5); and printf("%s", 5);

errors, then? How much knowledge about the standard libraries are you
willing to bring into the language?

>> unlike "no-side-effect". Actually, specifying idempotent routines (with
>> side-effect) might help too.

> Maybe; don't know.

A call to an idempotent routine inside a loop may be optimized.

 Leo

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Tue,  9 Jul 2002 17:46:05 GMT xleobx@qmailcomq.com wrote:
> Why not make
>
> printf ("%d %s", 5); and printf("%s", 5);
>
> errors, then? How much knowledge about the standard libraries are you
> willing to bring into the language?

As much as given in the function prototype - no more, no less. The problem is,
however, there is no way to give this information in function prototype in
current language.

--
jk

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

xleobx@qmailcomq.com wrote
> Why not make
>
> printf ("%d %s", 5); and printf("%s", 5);
>
> errors, then?

These are errors.

The compiler isn't required to diagnose them. That doesn't mean
it's legal code.

(Are there any compilers that will diagnose those errors? I have
a hunch that some LINT utilities will, but how 'bout compilers?)

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Allan W wrote:
> xleobx@qmailcomq.com wrote
>
>>Why not make
>>
>>printf ("%d %s", 5); and printf("%s", 5);
>>
>>errors, then?
>
>
> These are errors.
>
> The compiler isn't required to diagnose them. That doesn't mean
> it's legal code.
>
> (Are there any compilers that will diagnose those errors? I have
> a hunch that some LINT utilities will, but how 'bout compilers?)

gcc certainly does, as does Gimpel's lint.  It would be possible
for a future C++ standard to require this checking, but it doesn't
seem (to me) worth the effort when C++ has type safe approaches
which should (normally) be encouraged as alternatives to *printf.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

<xleobx@qmailcomq.com> wrote in message
news:8u6V8.13028$T_.272873@iad-read.news.verio.net...
>
> This immediately prompts the question a la "C++0x wish list": why isn't
> there a keyword (or a creative reuse of an existing keyword) that would
> allow the user to tell the compiler that f() has no side-effects
> (or, rather, that f() should be treated as having no side-effects)?

How about "const"?  It's already a keyword, and already has similar meaning.
For a non-member function, you would simply add const (like you would with a
member function, but since it's not a member, the const implies that it is
globally constant):

void foo() const {
  //...
}

In the case of a member function, you would use "const const", since a
function can't be globally constant without also being locally constant...

void Foo::foo() const const {
  //...
}

Just a thought.

Ken


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3D21C775.55619839@acm.org...
> Mike Schilling wrote:
> >
> > "Pete Becker" <petebecker@acm.org> wrote in message
> > news:3D1F4B13.1388CC7F@acm.org...
> > > Mike Schilling wrote:
> > > >
> > > > "Rob Staveley (Tom)" <rstaveley@seseit.com> wrote in message
> > > > news:afjt57$14h$1@thorium.cix.co.uk...
> > > > > "if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can
be
> > > > > optimised with the appropriate compiler setting.
> > > > >
> > > > > Boolean expressions are evaluated from left to right and func()
should
> > be
> > > > > evaluated before 0.
> > > > "&" doesn't create a boolean expression; it's a bitwise and.
Bitwise
> > > > operators never short-circuit.  Even though "(0 & expr)" is
obviously
> > always
> > > > 0, "expr" will be evaluated.
> >
> > Note the above.
> >
> > > >
> > > > >
> > > > > With the appropriate compiler setting an "and-ed" expression can
be
> > > > > short-circuited when the first bit of it is false.
> > > > There are no relevant compiler settings.  The operators && and ||
> > (logical
> > > > "and" and "or" respectively) always short-circuit.  That is
> > > >
> > > >    bool notEmpty(char *s)
> > > >    {
> > > >         return s && (*s != 0);
> > > >    }
> > > >
> > > > is always safe.
> > > >
> > >
> > > Please note, however, that the question involved &, not &&. Compilers
> > > are not allowed to short-circuit &.
> > >
> > As I said.  Do we disagree?
> >
>
> Yes, on the appropriateness of discussing short-circuit behavior of &&
> when someone asks about &.
>


The original poster was discussing "boolean expressions" and "false".  Do
you think he was really asking about "&" or "&&"?

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <ag4nrk$ihn$1@eeyore.INS.cwru.edu>, Ken Alverson
<Ken@Alverson.com> writes
><xleobx@qmailcomq.com> wrote in message
>news:8u6V8.13028$T_.272873@iad-read.news.verio.net...
>>
>> This immediately prompts the question a la "C++0x wish list": why isn't
>> there a keyword (or a creative reuse of an existing keyword) that would
>> allow the user to tell the compiler that f() has no side-effects
>> (or, rather, that f() should be treated as having no side-effects)?
>
>How about "const"?  It's already a keyword, and already has similar meaning.
>For a non-member function, you would simply add const (like you would with a
>member function, but since it's not a member, the const implies that it is
>globally constant):

That would be a nightmare. The meaning as applied to member functions is
nothing like what we are thinking about. Doesn't change implicit
parameter versus has no side effects.

--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Ken Alverson <Ken@alverson.com> wrote:

>> This immediately prompts the question a la "C++0x wish list": why isn't
>> there a keyword (or a creative reuse of an existing keyword) that would
>> allow the user to tell the compiler that f() has no side-effects
>> (or, rather, that f() should be treated as having no side-effects)?

> How about "const"?  It's already a keyword, and already has similar meaning.

Maybe, but const seems to be overloaded enough already.

> For a non-member function, you would simply add const (like you would with a
> member function, but since it's not a member, the const implies that it is
> globally constant):

> void foo() const {
>   //...
> }

The GCC function attribute "const" means something different and much more
strict, while also worth including in the standard. And there is no use having
void functions with this attribute.

> In the case of a member function, you would use "const const", since a
> function can't be globally constant without also being locally constant...

Unfortunately this is not true. A locally non-constant member may be globally
constant _for user purposes_. Using "mutable" just for work around it is, IMO,
an overkill.

> void Foo::foo() const const {
>   //...
> }

> Just a thought.

The class of functions we're considering is less strict than
what GCC considers suitable for its attributes "pure" and "const". So it may
not be a very good idea to use "const" for that, but rather something
akin to '= 0' for pure virtual functions:

int foo() = "no-side-effect" { ... }

Why constrain ourselves with integer literals to specify function attributes?

 Leo

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

xleobx@qmailcomq.com wrote:
[...]
> int foo() = "no-side-effect" { ... }
>
> Why constrain ourselves with integer literals to specify function attributes?

PMFJI... I personally don't care much about "no-side-effect"
["yes-side-effect"], but what I really, REALLY need is this:

                 >>"async-cancel-safe"<<

regards,
alexander.

--
Every library routine should specify whether or not it is
async-cancel safe so that programmers know which routines
can be called from code that is asynchronously cancelable.
                                                       --
                         POSIX:'Part B: System Interfaces'

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Mike Schilling wrote:
>
> The original poster was discussing "boolean expressions" and "false".  Do
> you think he was really asking about "&" or "&&"?
>

Read the title of the thread.

--
Pete Becker
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.jamesd.demon.co.uk/csc/faq.html                       ]

Alexander Terekhov <terekhov@web.de> wrote:

> PMFJI... I personally don't care much about "no-side-effect"
> ["yes-side-effect"], but what I really, REALLY need is this:

>                  >>"async-cancel-safe"<<

> Every library routine should specify whether or not it is
> async-cancel safe so that programmers know which routines
> can be called from code that is asynchronously cancelable.
>                                                        --
>                          POSIX:'Part B: System Interfaces'

So it is a QoI issue (the compiler will be able to issue a warning),
but specifying the attribute will not result in an improvement in efficiency,
unlike "no-side-effect". Actually, specifying idempotent routines (with
side-effect) might help too.

 Leo

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Mike Schilling <mscottschilling@hotmail.com> wrote:

> The as-if rule applies.  If the compiler is certain there are no
> side-effects of evaluating "expr", it's free not to do so.  If there are

Which pretty much limits the optimization to the cases when all
(transitive closure) functions and methods mentioned in an expression
are inlined.

> side effects, they must occur as if expr were fully evaluated.  Thus:

>     0 & ((x + y - z << 12) * (w >> (p ? i : j)))

> No need to evaluate.

>     0 & f()

> Unless the compiler can guarantee that f() has no side effects, it must be
> called.  Note that there's no need to actually and the return value with 0;
> hardcoding 0 as the result of the expression is acceptable.

This immediately prompts the question a la "C++0x wish list": why isn't
there a keyword (or a creative reuse of an existing keyword) that would
allow the user to tell the compiler that f() has no side-effects
(or, rather, that f() should be treated as having no side-effects)?

 Leo

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

I saw a closely related but odd relative of this once.  Consider the
following

int bar( void );

int foo( void )
{
    return some_const_value * bar();
}

due to a bug, some_const_value had the value zero, so the result of the
expression was always zero.  The compiler worked this out and produced the
following (pseudo) code

call bar
return zero (ignore result of bar)

so it was discarding the answer but still calling the fn.  Quite correct but
it took a little while to find in the debugger, as the code always called
bar but did not depend on the answer.

Matthew


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Sherlog wrote:
 > I certainly would expect the compiler to optimize away
> anything that has
>    foo & 0
> or
>    0 & foo
> in it - regardless of what foo actually is. Does the Standard require foo
> to be evaluated (not merely allow but *require*)?

As you noted, since foo & 0 and 0 & foo always produce 0, foo doesn't
have to be evaluated at all *except if it has side-effects*. If foo here
   is a function call foo(), and the compiler doesn't have access to its
code (so that a really good optimising compiler could check whether
foo() has side-effects or not), then the compiler must call foo(), even
if it doesn't use its return value.

This is one of the reasons why some sort of side-effect-free annotation
in function prototypes is quite high on my C++0x wishlist. :-)

--
------------ Matti Rintala -------- matti.rintala@tut.fi ---------
"When the remarkable turns bizarre, reason turns rancid."
            Cheshire Cat in "American McGee's Alice"

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3D1F4B13.1388CC7F@acm.org...
> Mike Schilling wrote:
> >
> > "Rob Staveley (Tom)" <rstaveley@seseit.com> wrote in message
> > news:afjt57$14h$1@thorium.cix.co.uk...
> > > "if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can be
> > > optimised with the appropriate compiler setting.
> > >
> > > Boolean expressions are evaluated from left to right and func() should
be
> > > evaluated before 0.
> > "&" doesn't create a boolean expression; it's a bitwise and.  Bitwise
> > operators never short-circuit.  Even though "(0 & expr)" is obviously
always
> > 0, "expr" will be evaluated.

Note the above.

> >
> > >
> > > With the appropriate compiler setting an "and-ed" expression can be
> > > short-circuited when the first bit of it is false.
> > There are no relevant compiler settings.  The operators && and ||
(logical
> > "and" and "or" respectively) always short-circuit.  That is
> >
> >    bool notEmpty(char *s)
> >    {
> >         return s && (*s != 0);
> >    }
> >
> > is always safe.
> >
>
> Please note, however, that the question involved &, not &&. Compilers
> are not allowed to short-circuit &.
>
As I said.  Do we disagree?

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3d2187d7$97c983@meow-labs.de>, Sherlog <sherlog@meow-labs.de> wrote:

> Mike Schilling in <OwxT8.310$GU6.31814767@newssvr14.news.prodigy.com>:
>
> > "Rob Staveley (Tom)" <rstaveley@seseit.com> wrote in message
> > news:afjt57$14h$1@thorium.cix.co.uk...
> > > "if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can be
> > > optimised with the appropriate compiler setting.
> ...
> > "&" doesn't create a boolean expression; it's a bitwise and.  Bitwise
> > operators never short-circuit.  Even though "(0 & expr)" is obviously always
> > 0, "expr" will be evaluated.
>
> Huh? I was under the impression that for bitwise & the evaluation order
> is undefined and that therefore the compiler is free to pick whatever it
> thinks best. I certainly would expect the compiler to optimize away
> anything that has
>    foo & 0
> or
>    0 & foo
> in it - regardless of what foo actually is. Does the Standard require foo
> to be evaluated (not merely allow but *require*)?
>
> I could not find anything to that effect - but I am not an expert at
> reading & interpreting Scripture. <g>

What is the rationale for not having any defined grouping order for
bitwise operators ?

e.g. 1 & 0 |   1 -> undefined result

This is a source for subtle bugs, if it doesn't pay of in other areas, why
is i like this ?


frode

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Sherlog" <sherlog@meow-labs.de> wrote in message
news:3d2187d7$97c983@meow-labs.de...
> Mike Schilling in <OwxT8.310$GU6.31814767@newssvr14.news.prodigy.com>:
>
> > "Rob Staveley (Tom)" <rstaveley@seseit.com> wrote in message
> > news:afjt57$14h$1@thorium.cix.co.uk...
> > > "if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can be
> > > optimised with the appropriate compiler setting.
> ...
> > "&" doesn't create a boolean expression; it's a bitwise and.  Bitwise
> > operators never short-circuit.  Even though "(0 & expr)" is obviously
always
> > 0, "expr" will be evaluated.
>
> Huh? I was under the impression that for bitwise & the evaluation order
> is undefined and that therefore the compiler is free to pick whatever it
> thinks best. I certainly would expect the compiler to optimize away
> anything that has
>    foo & 0
> or
>    0 & foo
> in it - regardless of what foo actually is. Does the Standard require foo
> to be evaluated (not merely allow but *require*)?
>
> I could not find anything to that effect - but I am not an expert at
> reading & interpreting Scripture. <g>

The as-if rule applies.  If the compiler is certain there are no
side-effects of evaluating "expr", it's free not to do so.  If there are
side effects, they must occur as if expr were fully evaluated.  Thus:

    0 & ((x + y - z << 12) * (w >> (p ? i : j)))

No need to evaluate.

    0 & f()

Unless the compiler can guarantee that f() has no side effects, it must be
called.  Note that there's no need to actually and the return value with 0;
hardcoding 0 as the result of the expression is acceptable.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Mike Schilling wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3D1F4B13.1388CC7F@acm.org...
> > Mike Schilling wrote:
> > >
> > > "Rob Staveley (Tom)" <rstaveley@seseit.com> wrote in message
> > > news:afjt57$14h$1@thorium.cix.co.uk...
> > > > "if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can be
> > > > optimised with the appropriate compiler setting.
> > > >
> > > > Boolean expressions are evaluated from left to right and func() should
> be
> > > > evaluated before 0.
> > > "&" doesn't create a boolean expression; it's a bitwise and.  Bitwise
> > > operators never short-circuit.  Even though "(0 & expr)" is obviously
> always
> > > 0, "expr" will be evaluated.
>
> Note the above.
>
> > >
> > > >
> > > > With the appropriate compiler setting an "and-ed" expression can be
> > > > short-circuited when the first bit of it is false.
> > > There are no relevant compiler settings.  The operators && and ||
> (logical
> > > "and" and "or" respectively) always short-circuit.  That is
> > >
> > >    bool notEmpty(char *s)
> > >    {
> > >         return s && (*s != 0);
> > >    }
> > >
> > > is always safe.
> > >
> >
> > Please note, however, that the question involved &, not &&. Compilers
> > are not allowed to short-circuit &.
> >
> As I said.  Do we disagree?
>

Yes, on the appropriateness of discussing short-circuit behavior of &&
when someone asks about &.

--
Pete Becker
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.jamesd.demon.co.uk/csc/faq.html                       ]

Is it legal for a compiler to optimize the expression
>if (func () & 0)
completly out, without executing the func ();

Regards,
Miklos

Ie.: is the following C++ program well defined

#include <iostream>

namespace {

int func (void)
{
 std::cout << "Test" << std::endl;
 return 0;
}

}

int main(void)
{
 if (func () & 0) {}

 return 0;
}

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can be
optimised with the appropriate compiler setting.

Boolean expressions are evaluated from left to right and func() should be
evaluated before 0.

With the appropriate compiler setting an "and-ed" expression can be
short-circuited when the first bit of it is false.

"Mikl   s Fazekas" <boga@mac.com> wrote in message
news:22076b09.0206280012.610fbbc1@posting.google.com...
> Is it legal for a compiler to optimize the expression
> >if (func () & 0)
> completly out, without executing the func ();
>
> Regards,
> Miklos
>
> Ie.: is the following C++ program well defined
>
> #include <iostream>
>
> namespace {
>
> int func (void)
> {
> std::cout << "Test" << std::endl;
> return 0;
> }
>
> }
>
> int main(void)
> {
> if (func () & 0) {}
>
> return 0;
> }
>
> ---
> [ 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.jamesd.demon.co.uk/csc/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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Rob Staveley (Tom)" <rstaveley@seseit.com> wrote in message
news:afjt57$14h$1@thorium.cix.co.uk...
> "if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can be
> optimised with the appropriate compiler setting.
>
> Boolean expressions are evaluated from left to right and func() should be
> evaluated before 0.
"&" doesn't create a boolean expression; it's a bitwise and.  Bitwise
operators never short-circuit.  Even though "(0 & expr)" is obviously always
0, "expr" will be evaluated.

>
> With the appropriate compiler setting an "and-ed" expression can be
> short-circuited when the first bit of it is false.
There are no relevant compiler settings.  The operators && and || (logical
"and" and "or" respectively) always short-circuit.  That is

   bool notEmpty(char *s)
   {
        return s && (*s != 0);
   }

is always safe.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Mike Schilling wrote:
>
> "Rob Staveley (Tom)" <rstaveley@seseit.com> wrote in message
> news:afjt57$14h$1@thorium.cix.co.uk...
> > "if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can be
> > optimised with the appropriate compiler setting.
> >
> > Boolean expressions are evaluated from left to right and func() should be
> > evaluated before 0.
> "&" doesn't create a boolean expression; it's a bitwise and.  Bitwise
> operators never short-circuit.  Even though "(0 & expr)" is obviously always
> 0, "expr" will be evaluated.
>
> >
> > With the appropriate compiler setting an "and-ed" expression can be
> > short-circuited when the first bit of it is false.
> There are no relevant compiler settings.  The operators && and || (logical
> "and" and "or" respectively) always short-circuit.  That is
>
>    bool notEmpty(char *s)
>    {
>         return s && (*s != 0);
>    }
>
> is always safe.
>

Please note, however, that the question involved &, not &&. Compilers
are not allowed to short-circuit &.

--
Pete Becker
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.jamesd.demon.co.uk/csc/faq.html                       ]

Quite right! Is it better to say "the yoke of and is *is* white" or "the
yoke of an egg *are* white"? %-)

> "&" doesn't create a boolean expression; it's a bitwise and.  Bitwise
> operators never short-circuit.  Even though "(0 & expr)" is obviously
always
> 0, "expr" will be evaluated.



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <22076b09.0206280012.610fbbc1@posting.google.com>,
boga@mac.com says...
> Is it legal for a compiler to optimize the expression
> >if (func () & 0)
> completly out, without executing the func ();
No, I don't believe so. The bitwise operations do not short-circuit, so
both operands are required to be evaluated.

--
Jim

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Rob Staveley (Tom)" <rstaveley@seseit.com> wrote in message
news:afjt57$14h$1@thorium.cix.co.uk...
> "if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can be
> optimised with the appropriate compiler setting.
>
> Boolean expressions are evaluated from left to right and func() should
be
> evaluated before 0.
>
> With the appropriate compiler setting an "and-ed" expression can be
> short-circuited when the first bit of it is false.

& does not guarantee left-to-right evaluation.

--
Dag Henriksson


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <afjt57$14h$1@thorium.cix.co.uk>, "Rob Staveley \(Tom\)"
<rstaveley@seseit.com> says...
> "if (func () & 0)" shouldn't optimise, but "if (0 & func ())" can be
> optimised with the appropriate compiler setting.
>
> Boolean expressions are evaluated from left to right and func() should be
> evaluated before 0.
Except that this is not the boolean AND (&&), it is the bitwise AND (&).

--
Jim

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]