Topic: Operator || precedence
Author: jim.hyslop@leitch.com
Date: 1998/12/21 Raw View
In article <75c6i2$l5i$1@nnrp1.dejanews.com>,
AllanW@my-dejanews.com wrote:
> > OY!!!! How complicated can you get?
> With a tiny bit of effort, we can get much more complicated than
> anything you've seen so far on this thread.
No thanks, life's is complicated enough as it is without deliberately muddling
things up ;-)
[snip]
> Doesn't really belong as part of a summary, does it? comp.std.c++
> deals with standards issues. As such, it can't afford to talk
> about programs written according to Meyers....
[snip]
With due respect, Allan, perhaps you should let the moderators decide which
posts belong in comp.std.c++ and which do not. Please also check the
cross-posts - I am reading this thread in comp.lang.c++, not comp.std.c++.
[ moderator's note: Whether or not an article is cross-posted to other
newsgroups, we comp.std.c++ moderators decide whether to approve or
reject the article based solely on its suitability according to the
newsgroup charter. See the FAQ for more details. -sdc ]
> > 2) The first expression is evaluated completely. If the result of that
> > evaluation forces the final result (i.e. if op|| and the first result is
> > true, or op&& and the first result is false), then no further evaluation is
> > performed. That includes side effects of the second and subsequent
> > expressions. Repeat with each remaining expression, in order, until the
> > final result is obtained.
>
> Even if we accept your premise in 1), this is still not sufficient.
> Since it mentions both operator|| and operator&&, it implies that
> it works even when they are mixed. But this is not true; operator&&
> has higher precedence.
Ah, yes, there's always something to complicate the formula, isn't there? :-)
You're right, I should have kept it simple by not mentioning both operators in
the same breath. Or perhaps I should have added a caveat that mixing the two
operators complicates the entire procedure. Even the Standard does not touch
that subject - for example, given built-in types (or functions that return
built-in types) A, B and C, in the expression:
A || B && C
The Standard guarantees that, in the OR expression, A will be evaluated
first. But the Standard also requires that op && be evaluated before op||,
therefore B must be evaluated before A.
--
Jim
Note to recruitment agencies: I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: sbnaran@localhost.localdomain.COM (Siemel Naran)
Date: 1998/12/21 Raw View
On 21 Dec 1998 17:18:34 GMT, jim.hyslop@leitch.com <jim.hyslop@leitch.com>
> AllanW@my-dejanews.com wrote:
>> Doesn't really belong as part of a summary, does it? comp.std.c++
>> deals with standards issues. As such, it can't afford to talk
>> about programs written according to Meyers....
Yes, standard C++ seems to be more general than Scott Meyers. If
the single arg constructor of class X is explicit, then overloading
operator|| and operator&& seems ok, as in
(x1||x2); // calls X::operator||(const X&)
'x1' and 'x2' must be already evaluated before the operator|| is
entered. Similar remarks hold for operator,.
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ 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 ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/12/21 Raw View
jim.hyslop@leitch.com writes:
>You're right, I should have kept it simple by not mentioning both operators in
>the same breath. Or perhaps I should have added a caveat that mixing the two
>operators complicates the entire procedure. Even the Standard does not touch
>that subject - for example, given built-in types (or functions that return
>built-in types) A, B and C, in the expression:
>A || B && C
>The Standard guarantees that, in the OR expression, A will be evaluated
>first. But the Standard also requires that op && be evaluated before op||,
>therefore B must be evaluated before A.
Not at all. The precedence rules make the expression equivalent to
A || (B && C)
but precedence alone does not determine a total order of evaluation.
Indeed, the || operator has a sequence point after evaluation of the
left operand (see 1.9, paragraph 18).
In the context of built-in types, the rule for the logical-or operator
is that the right-hand operand is not evaluated unless the left-hand
operand is false. The expression is thus equivalent, sequence points
and all, to
A ? true : (B && C)
--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <dtribble@technologist.com>
Date: 1998/12/21 Raw View
jim.hyslop@leitch.com writes:
> A || B && C
> The Standard guarantees that, in the OR expression, A will be
> evaluated first. But the Standard also requires that op && be
> evaluated before op||, therefore B must be evaluated before A.
Steve Clamage wrote:
> Not at all. The precedence rules make the expression equivalent to
> A || (B && C)
> but precedence alone does not determine a total order of evaluation.
> Indeed, the || operator has a sequence point after evaluation of the
> left operand (see 1.9, paragraph 18).
>
> In the context of built-in types, the rule for the logical-or operator
> is that the right-hand operand is not evaluated unless the left-hand
> operand is false. The expression is thus equivalent, sequence points
> and all, to
> A ? true : (B && C)
Yes, in the case of built-in operator|| and operator&&. This
expression is evaluated using short-circuit evaluation.
But a few posts back, someone questioned the ordering for user-
defined operators. In this case, if both || and && are user-defined
functions, the 'A || B && C' expression is exactly equivalent to:
A.operator||(B.operator&&(C));
or:
operator||(A, operator&&(B, C));
There is no short-circuit evaluation, which means that all three
operands are evaluated. The only difference between the two
operators is their precedence, which in this case does determine
evaluation order (bacause we're dealing with function calls instead
of built-in operators), hence the && is evaluated before the ||.
And since the operators are actually function calls, there will be a
sequence point (if I'm not mistaken) immediately before
operator&& is called and immediately before operator|| is called.
-- David R. Tribble, dtribble@technologist.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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/12/22 Raw View
In article <3675FB04.363A624B@xroads.com>, David Wieringa
<wieringa@xroads.com> wrote:
>In a recent code walk-thru at work, someone suggested that different
>compilers process logical OR's differently.
>
>e.g. In the code "if( x || y || z) { ... }", you can't be guarantee
>that x will be evaluated before y or z.
>
>They didn't disagree that if the first (or second) expression evaluated
>to true that the compiler would ignore the remaining expressions.
>
>Can someone solve this disagreement?
In article <walke751.NOSPAM-1512982125030001@ts002d44.nor-ct.concentric.net>,
walke751.NOSPAM@concentric.net (Daryle Walker) wrote:
> From previous posts here, others indicate that operator|| has some special
> ordering properties. Here is what I think a summary of these could be:
[Mostly correct synopsis, with a few minor inaccuracies]
In article <75b5b7$n5f$1@nnrp1.dejanews.com>,
jim.hyslop@leitch.com wrote:
> OY!!!! How complicated can you get?
Perhaps you're complaining that the rule is too complex for you
to understand. But it sounds to me as if you're whining about
Daryle Walker making things more complex than they really are.
If so, you are inaccurate.
> OK, here's a SIMPLE summary:
>
> 1) Don't overload operator || or operator && (see Meyers, "Effective C++" -
> or is that one in "More Effective C++"? - for a detailed explanation why)
>
> That cuts out most of the stuff above, and leaves you with operator || and
> op&& for built-in types, the rule for which is simple:
In article <75c6i2$l5i$1@nnrp1.dejanews.com>,
AllanW@my-dejanews.com wrote:
[Summary point #1 above]
> Doesn't really belong as part of a summary, does it? comp.std.c++
> deals with standards issues. As such, it can't afford to talk
> about programs written according to Meyers....
In article <75lqvk$947$1@nnrp1.dejanews.com>,
jim.hyslop@leitch.com wrote:
> [snip]
> With due respect, Allan, perhaps you should let the moderators decide which
> posts belong in comp.std.c++ and which do not. Please also check the
> cross-posts - I am reading this thread in comp.lang.c++, not comp.std.c++.
>
> [ moderator's note: Whether or not an article is cross-posted to other
> newsgroups, we comp.std.c++ moderators decide whether to approve or
> reject the article based solely on its suitability according to the
> newsgroup charter. See the FAQ for more details. -sdc ]
With exactly as much respect, jim, I didn't say anything about the
moderation policy. I said that your remarks don't belong in a
summary of operator||.
Read the question above, again. David Wieringa asked some detailed
questions about operator||. The correct answer begins to explain the
concept of sequence points, and Daryle Walker did just that. But you
ridiculed him, and supplied your own answer: Don't overload it.
Forgive me for saying so, but that simply isn't appropriate.
And you too should read the cross-posts. I am reading this in
comp.std.c++. Surely there is some overlap between the two
groups, something along the lines of "using the C++ standard
to produce robust and portable programs." Not "why you shouldn't
ever do that stuff."
> > > 2) The first expression is evaluated completely. If the result of that
> > > evaluation forces the final result (i.e. if op|| and the first result is
> > > true, or op&& and the first result is false), then no further evaluation
> > > is performed. That includes side effects of the second and subsequent
> > > expressions. Repeat with each remaining expression, in order, until the
> > > final result is obtained.
> >
> > Even if we accept your premise in 1), this is still not sufficient.
> > Since it mentions both operator|| and operator&&, it implies that
> > it works even when they are mixed. But this is not true; operator&&
> > has higher precedence.
>
> Ah, yes, there's always something to complicate the formula, isn't there? :-)
>
> You're right, I should have kept it simple by not mentioning both operators in
> the same breath. Or perhaps I should have added a caveat that mixing the two
> operators complicates the entire procedure. Even the Standard does not touch
> that subject - for example, given built-in types (or functions that return
> built-in types) A, B and C, in the expression:
>
> A || B && C
>
> The Standard guarantees that, in the OR expression, A will be evaluated
> first. But the Standard also requires that op && be evaluated before op||,
> therefore B must be evaluated before A.
The standard does not leave this ambiguous. Do not confuse
precedence with order of evaluation. This expression groups
as (A||B)&&C. The order of evaluation of most expressions is
not defined, but || and && are exceptions -- the left operand
is always evaluated first, and the right operand might not be
evaluated at all. In this case, A is evaluated first; B is
evaluated second, but only if A is false; and C is evaluated
last, but only if A||B is true. So we have:
A B C Result
- - - ------
T x x True
F T T True
F T F False
F F x False
where x means "not evaluated."
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: Hyman Rosen <hymie@prolifics.com>
Date: 1998/12/22 Raw View
David R Tribble wrote:
> operator||(A, operator&&(B, C));
>
> There is no short-circuit evaluation, which means that all three
> operands are evaluated. The only difference between the two
> operators is their precedence, which in this case does determine
> evaluation order (bacause we're dealing with function calls instead
> of built-in operators), hence the && is evaluated before the ||.
>
> And since the operators are actually function calls, there will be a
> sequence point (if I'm not mistaken) immediately before
> operator&& is called and immediately before operator|| is called.
All correct. It is, of course, still the case that the implementation
is free to evaluate A, B, and C in any order.
[ 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 ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/12/22 Raw View
AllanW@my-dejanews.com wrote:
>
> In article <3675FB04.363A624B@xroads.com>, David Wieringa
> <wieringa@xroads.com> wrote:
....
> > A || B && C
> >
> > The Standard guarantees that, in the OR expression, A will be evaluated
> > first. But the Standard also requires that op && be evaluated before op||,
> > therefore B must be evaluated before A.
>
> The standard does not leave this ambiguous. Do not confuse
> precedence with order of evaluation. This expression groups
> as (A||B)&&C. The order of evaluation of most expressions is
Are you sure about that? I thought it was A||(B&&C).
[ 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 ]
Author: jim.hyslop@leitch.com
Date: 1998/12/22 Raw View
In article <75m5qn$c9e$1@engnews2.Eng.Sun.COM>,
stephen.clamage@sun.com (Steve Clamage) wrote:
[snip]
> Not at all. The precedence rules make the expression equivalent to
> A || (B && C)
> but precedence alone does not determine a total order of evaluation.
> Indeed, the || operator has a sequence point after evaluation of the
> left operand (see 1.9, paragraph 18).
Wait a minute - does this mean that my original summary is correct, and mixing
the two operators doesn't matter (for built in types - let me emphasize that!)
--
Jim
Note to recruitment agencies: I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: jim.hyslop@leitch.com
Date: 1998/12/22 Raw View
In article <75mmm7$1i8$1@nnrp1.dejanews.com>,
AllanW@my-dejanews.com wrote:
[snip]
> > > > 2) The first expression is evaluated completely. If the result of that
> > > > evaluation forces the final result (i.e. if op|| and the first result is
> > > > true, or op&& and the first result is false), then no further evaluation
> > > > is performed. That includes side effects of the second and subsequent
> > > > expressions. Repeat with each remaining expression, in order, until the
> > > > final result is obtained.
(the above quote retained for reference below...)
[snip]
> > The Standard guarantees that, in the OR expression, A will be evaluated
> > first. But the Standard also requires that op && be evaluated before op||,
> > therefore B must be evaluated before A.
>
> The standard does not leave this ambiguous.
I never said it did. I should have stated explicitly that my final statement
("B must be evaluated before A") is the one that will be observed (by whatever
route through the rules you choose to take).
> Do not confuse
> precedence with order of evaluation. This expression groups
> as (A||B)&&C. The order of evaluation of most expressions is
> not defined, but || and && are exceptions -- the left operand
> is always evaluated first, and the right operand might not be
> evaluated at all. In this case, A is evaluated first; B is
> evaluated second, but only if A is false; and C is evaluated
> last, but only if A||B is true.
Isn't that what I said in my point (2) above?
> So we have:
> A B C Result
> - - - ------
> T x x True
> F T T True
> F T F False
> F F x False
>
> where x means "not evaluated."
Which is exactly the effect I described in my original point (2). Thanks for
arguing on my behalf, Allan :-)
--
Jim
Note to recruitment agencies: I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: jim.hyslop@leitch.com
Date: 1998/12/22 Raw View
In article <75m5qn$c9e$1@engnews2.Eng.Sun.COM>,
stephen.clamage@sun.com (Steve Clamage) wrote:
>
[snip]
> Not at all. The precedence rules make the expression equivalent to
> A || (B && C)
> but precedence alone does not determine a total order of evaluation.
> Indeed, the || operator has a sequence point after evaluation of the
> left operand (see 1.9, paragraph 18).
Does the number of sequence points extend to multiple operations? For
example, given built-in types A, B, C, D, how many sequence points are there
in:
A && B || C && D
Are there potentially three sequence points (if A and C are true, B is false
so we must evaluate D) or is there still only one sequence point after
evaluating A? Are there still three sequence points if A is false (I presume
B will not be evaluated), or if A and B are both true (neither C nor D will
be evaluated)?
--
Jim
Note to recruitment agencies: I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: James.Kanze@dresdner-bank.com
Date: 1998/12/22 Raw View
In article <75lqvk$947$1@nnrp1.dejanews.com>,
jim.hyslop@leitch.com wrote:
>
> In article <75c6i2$l5i$1@nnrp1.dejanews.com>,
> AllanW@my-dejanews.com wrote:
> You're right, I should have kept it simple by not mentioning both
> operators in the same breath. Or perhaps I should have added a caveat
> that mixing the two operators complicates the entire procedure. Even
> the Standard does not touch that subject - for example, given built-in
> types (or functions that return built-in types) A, B and C, in the
> expression:
> A || B && C
>
> The Standard guarantees that, in the OR expression, A will be evaluated
> first. But the Standard also requires that op && be evaluated before op||,
> therefore B must be evaluated before A.
Are you sure? I don't remember the precedence, and I don't have any C++
books handy to verify it. But either way, A must be evaluated before B.
If the grouping is ` A || (B && C) ', as I interpret it to be from your
comment, then the second sub-expression may not be evaluated at all if A
is true.
Note that there is nothing in the standard which specified the ordering
of operators -- only the ordering of the side effects of expressions.
In the above example, the ordering constraints are:
A before (B && C)
B before C
--
James Kanze GABI Software, S rl
Conseils en informatique orient objet --
-- Beratung in industrieller Datenverarbeitung
mailto: kanze@gabi-soft.fr mailto: James.Kanze@dresdner-bank.com
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: AllanW@my-dejanews.com
Date: 1998/12/22 Raw View
In article <367ECC88.AD36710A@technologist.com>,
David R Tribble <dtribble@technologist.com> wrote:
>
> jim.hyslop@leitch.com writes:
> > A || B && C
[...]
> a few posts back, someone questioned the ordering for user-
> defined operators. In this case, if both || and && are user-defined
> functions, the 'A || B && C' expression is exactly equivalent to:
>
> A.operator||(B.operator&&(C));
> or:
> operator||(A, operator&&(B, C));
>
> There is no short-circuit evaluation, which means that all three
> operands are evaluated.
Correct
> The only difference between the two
> operators is their precedence, which in this case does determine
> evaluation order (bacause we're dealing with function calls instead
> of built-in operators), hence the && is evaluated before the ||.
True but misleading. Because B and C are operands of &&, they must
be evaluated before && is called. And because A and the result of
&& are operands of ||, they must both be evaluated before || is
called. But other than that, the compiler has a lot of liberty.
For instance, it can evaluate A either before B and C, or after
B and C but before the call to &&, or after returning from && but
before calling ||.
> And since the operators are actually function calls, there will be a
> sequence point (if I'm not mistaken) immediately before
> operator&& is called and immediately before operator|| is called.
Yes, there is a sequence point after B and C are evaluated
and before && is called. But it's legal to evaluate A BEFORE
this sequence point. There's another one after returning
from &&, and still another one sometime after && has finished
and A has been evaluated, and before || is called.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/12/22 Raw View
jim.hyslop@leitch.com writes:
>In article <75m5qn$c9e$1@engnews2.Eng.Sun.COM>,
> stephen.clamage@sun.com (Steve Clamage) wrote:
>>
>[snip]
>> Not at all. The precedence rules make the expression equivalent to
>> A || (B && C)
>> but precedence alone does not determine a total order of evaluation.
>> Indeed, the || operator has a sequence point after evaluation of the
>> left operand (see 1.9, paragraph 18).
>Does the number of sequence points extend to multiple operations? For
>example, given built-in types A, B, C, D, how many sequence points are there
>in:
> A && B || C && D
>Are there potentially three sequence points (if A and C are true, B is false
>so we must evaluate D) or is there still only one sequence point after
>evaluating A? Are there still three sequence points if A is false (I presume
>B will not be evaluated), or if A and B are both true (neither C nor D will
>be evaluated)?
You are making this much too difficult. Section 1.9 of the standard
describes the sequence points in C++. Where you have an instance of
a built-in operator && or ||, for example, there is a sequence point
after the evaluation of the left-hand operand. Nothing more needs to
be said.
In your example, there is a sequence point after the evaluation of
each of A, (A&&B), and C. It might happen that some of these sub-
expressions are not evaluated. In that case, the putative presence
of the associated sequence points is irrelevant.
--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/12/23 Raw View
In article <367F46B2.B8245497@wizard.net>,
James Kuyper <kuyper@wizard.net> wrote:
>
> AllanW@my-dejanews.com wrote:
> >
> > In article <3675FB04.363A624B@xroads.com>, David Wieringa
> > <wieringa@xroads.com> wrote:
> ....
> > > A || B && C
> >
> > The standard does not leave this ambiguous. Do not confuse
> > precedence with order of evaluation. This expression groups
> > as (A||B)&&C. The order of evaluation of most expressions is
>
> Are you sure about that? I thought it was A||(B&&C).
It is. This one line is a typo. Read the rest of that paragraph
and you'll see that I obviously meant A||(B&&C).
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: AllanW@my-dejanews.com
Date: 1998/12/23 Raw View
In article <75oa6b$ag5$1@nnrp1.dejanews.com>,
jim.hyslop@leitch.com wrote:
>
> In article <75m5qn$c9e$1@engnews2.Eng.Sun.COM>,
> stephen.clamage@sun.com (Steve Clamage) wrote:
> [snip]
> > Not at all. The precedence rules make the expression equivalent to
> > A || (B && C)
> > but precedence alone does not determine a total order of evaluation.
> > Indeed, the || operator has a sequence point after evaluation of the
> > left operand (see 1.9, paragraph 18).
>
> Wait a minute - does this mean that my original summary is correct, and mixing
> the two operators doesn't matter (for built in types - let me emphasize that!)
Consider A && B || C && D. If A is false, we skip the evaluation of B,
but we must still evaluate C (and potentially D).
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: AllanW@my-dejanews.com
Date: 1998/12/23 Raw View
In article <75oe7b$e49$1@nnrp1.dejanews.com>,
jim.hyslop@leitch.com wrote:
>
> In article <75m5qn$c9e$1@engnews2.Eng.Sun.COM>,
> stephen.clamage@sun.com (Steve Clamage) wrote:
> >
> [snip]
> > Not at all. The precedence rules make the expression equivalent to
> > A || (B && C)
> > but precedence alone does not determine a total order of evaluation.
> > Indeed, the || operator has a sequence point after evaluation of the
> > left operand (see 1.9, paragraph 18).
>
> Does the number of sequence points extend to multiple operations? For
> example, given built-in types A, B, C, D, how many sequence points are there
> in:
>
> A && B || C && D
>
> Are there potentially three sequence points (if A and C are true, B is false
> so we must evaluate D) or is there still only one sequence point after
> evaluating A? Are there still three sequence points if A is false (I presume
> B will not be evaluated), or if A and B are both true (neither C nor D will
> be evaluated)?
This is equivalent to (A&&B) || (C&&D).
If A is false, there is no need to evaluate B. If A&&B is true, there is no
need to evaluate C&&D. If C is false, there is no need to evaluate D.
A B C D Result
- - - - ------
T T x x True
T F T T True
T F T F False
T F F x False
F x T T True
F x T F False
F x F x False
where x means "not evaluated". Or, if you'll forgive my crude ASCII-art:
_____
/START\
\_____/
|
|
^
/ \
f / \
---< A >
/ \ /
/ \ /
| V
| | t
| |
| ^
| / \
| / \ t
| < B >---
| \ / \
| \ / \
\ V |
\ | f |
----->| |
^ |
/ \ |
f / \ |
---< C > |
/ \ / |
/ \ / |
| V |
| | t |
| | |
| ^ |
| / \ |
| / \ t |
| < D >--->|
| \ / |
| \ / |
\ V |
\ | f |
----->| |
__|__ __|__
/FALSE\ /TRUE \
\_____/ \_____/
Notice that except for D's TRUE path, a "sideways" path (left or
right) corresponds to a "short-circuit" path, since there's at
least one evaluation skipped. But also note that the only
evaluations skipped are the ones that do not influence the
outcome, such as C and D when A and B are both true, or B when
A is false.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: AllanW@my-dejanews.com
Date: 1998/12/23 Raw View
In article <75odhp$d9k$1@nnrp1.dejanews.com>,
jim.hyslop@leitch.com wrote:
>
> In article <75mmm7$1i8$1@nnrp1.dejanews.com>,
> AllanW@my-dejanews.com wrote:
> [snip]
>
> > > > > 2) The first expression is evaluated completely. If the result of that
> > > > > evaluation forces the final result (i.e. if op|| and the first result is
> > > > > true, or op&& and the first result is false), then no further evaluation
> > > > > is performed. That includes side effects of the second and subsequent
> > > > > expressions. Repeat with each remaining expression, in order, until the
> > > > > final result is obtained.
> (the above quote retained for reference below...)
>
> [snip]
> > > The Standard guarantees that, in the OR expression, A will be evaluated
> > > first. But the Standard also requires that op && be evaluated before op||,
> > > therefore B must be evaluated before A.
> >
> > The standard does not leave this ambiguous.
>
> I never said it did. I should have stated explicitly that my final statement
> ("B must be evaluated before A") is the one that will be observed (by whatever
> route through the rules you choose to take).
>
[Typo in following paragraph fixed:]
> > Do not confuse
> > precedence with order of evaluation. This expression groups
> > as A||(B&&C). The order of evaluation of most expressions is
> > not defined, but || and && are exceptions -- the left operand
> > is always evaluated first, and the right operand might not be
> > evaluated at all.
>
> Isn't that what I said in my point (2) above?
>
> > So we have:
> > A B C Result
> > - - - ------
> > T x x True
> > F T T True
> > F T F False
> > F F x False
> >
> > where x means "not evaluated."
>
> Which is exactly the effect I described in my original point (2). Thanks for
> arguing on my behalf, Allan :-)
Point (2) is correct with the built-in operators only. I believe that
in your original essay you ignored that quite vital fact. I'm not
even sure of that anymore ... all this reference to B's and A's
floating around in a sea of ||'s and &&'s is giving me a headache.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/12/23 Raw View
jim.hyslop@leitch.com wrote:
>
> In article <75m5qn$c9e$1@engnews2.Eng.Sun.COM>,
> stephen.clamage@sun.com (Steve Clamage) wrote:
> >
> [snip]
> > Not at all. The precedence rules make the expression equivalent to
> > A || (B && C)
> > but precedence alone does not determine a total order of evaluation.
> > Indeed, the || operator has a sequence point after evaluation of the
> > left operand (see 1.9, paragraph 18).
>
> Does the number of sequence points extend to multiple operations? For
> example, given built-in types A, B, C, D, how many sequence points are there
> in:
>
> A && B || C && D
>
> Are there potentially three sequence points (if A and C are true, B is false
> so we must evaluate D) or is there still only one sequence point after
> evaluating A? Are there still three sequence points if A is false (I presume
> B will not be evaluated), or if A and B are both true (neither C nor D will
> be evaluated)?
All those which _are_ evaluated are evaluated in the order given.
It is not interesting in which order the others are not evaluated
(not evaluating C after not evaluating D gives the same result
- nothing - as not evaluating D after not evaluating C).
However, since && has higher precedence than ||, the expression
is equivalent to (A && B) || (C && D), which means for evaluation:
(T = evaluated, gives true; F = evaluated, gives false;
? = not evaluated)
F?F? -> F
F?TF -> F
F?TT -> T
TFF? -> F
TFTF -> F
TFTT -> T
TT?? -> T
So it's possible that one expression is "skipped" and the next one
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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jim.hyslop@leitch.com
Date: 1998/12/23 Raw View
In article <75p24l$83j$1@engnews2.Eng.Sun.COM>,
stephen.clamage@sun.com (Steve Clamage) wrote:
[snip]
> You are making this much too difficult. Section 1.9 of the standard
> describes the sequence points in C++. Where you have an instance of
> a built-in operator && or ||, for example, there is a sequence point
> after the evaluation of the left-hand operand. Nothing more needs to
> be said.
But more *does* need to be said - the Standard talks about sequence points
when you have the simple case of one operator per statement, such as A || B,
but not when you have multiple operators in one statement (not an
unreasonable thing to do in your code). That's what I was trying to clarify.
> In your example, there is a sequence point after the evaluation of
> each of A, (A&&B), and C. It might happen that some of these sub-
> expressions are not evaluated. In that case, the putative presence
> of the associated sequence points is irrelevant.
That's what I was trying to get at. Thanks for the clarification.
--
Jim
Note to recruitment agencies: I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/12/23 Raw View
jim.hyslop@leitch.com writes:
>In article <75p24l$83j$1@engnews2.Eng.Sun.COM>,
> stephen.clamage@sun.com (Steve Clamage) wrote:
>[snip]
>> You are making this much too difficult. Section 1.9 of the standard
>> describes the sequence points in C++. Where you have an instance of
>> a built-in operator && or ||, for example, there is a sequence point
>> after the evaluation of the left-hand operand. Nothing more needs to
>> be said.
>But more *does* need to be said - the Standard talks about sequence points
>when you have the simple case of one operator per statement, such as A || B,
>but not when you have multiple operators in one statement (not an
>unreasonable thing to do in your code). That's what I was trying to clarify.
I still don't see your problem. Suppose you write a function
that happens not be called during a program run. Are you worried
about the sequence points inside that function? If so, why? If
not, how is that situation different from the case of unevaluated
sub-expressions?
A sequence point is a place in the program at which all prior
side effects must be complete. If between two sequence points
no code is executed, then the side effects (none) are certainly
complete.
--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jim.hyslop@leitch.com
Date: 1998/12/24 Raw View
In article <75rb3e$rf8$1@engnews2.Eng.Sun.COM>,
stephen.clamage@sun.com (Steve Clamage) wrote:
[snip]
> I still don't see your problem. Suppose you write a function
> that happens not be called during a program run. Are you worried
> about the sequence points inside that function? If so, why? If
> not, how is that situation different from the case of unevaluated
> sub-expressions?
I'm just trying to get a handle on sequence points, to make sure I understand
them properly - when they occur, etc. That's all. I hope you'll agree that
it's important to know where the sequence points will occur, so your program
always behaves the way you expect it to.
--
Jim
Note to recruitment agencies: I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/12/24 Raw View
In article <75rb3e$rf8$1@engnews2.Eng.Sun.COM>, Steve Clamage
<stephen.clamage@sun.com> writes
>A sequence point is a place in the program at which all prior
>side effects must be complete. If between two sequence points
>no code is executed, then the side effects (none) are certainly
>complete.
Steve, I think what he is hunting for is something like this (horrible
code but its the simples I can come up with that demonstrates the
problem:
int i=1, j=2, k=3, m=5;
int n;
n= (j=4, i=k) + (m=k, k=i);
The left and right subexpressions of + may be evaluated in any order.
There are sequence points after each ',' but they do not seem to help
with determing the value of n.
Francis Glassborow Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jim.hyslop@leitch.com
Date: 1998/12/24 Raw View
In article <36812179.546B16E1@physik.tu-muenchen.de>,
Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>
[snip]
> All those which _are_ evaluated are evaluated in the order given.
> It is not interesting in which order the others are not evaluated
> (not evaluating C after not evaluating D gives the same result
> - nothing - as not evaluating D after not evaluating C).
True, but I hope you'll agree that it is extremely important to *know* which
items may or may not be evaluated, and which ones may or may not have
sequence points. Whether or not the sequence point is actually hit is not as
important - knowing that there is a potential sequence point *IS* important.
[snip]
--
Jim
Note to recruitment agencies: I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: jim.hyslop@leitch.com
Date: 1998/12/24 Raw View
In article <75pikb$deb$1@nnrp1.dejanews.com>,
AllanW@my-dejanews.com wrote:
[snip]
> Point (2) is correct with the built-in operators only. I believe that
> in your original essay you ignored that quite vital fact.
No. My point (1) was that you should overloading operator || and operator &&
(a point which you took exception to for various reasons and we've covered
that ground, thank you, so don't anyone else hop in at this point to disagree
with it :-), that leaves you only with built-in operators for which I made my
point 2.
> I'm not
> even sure of that anymore ... all this reference to B's and A's
> floating around in a sea of ||'s and &&'s is giving me a headache.
Agreed - I think we've flogged this dead horse long enough; what say we give
it a rest?
Happy holidays!
--
Jim
Note to recruitment agencies: I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: AllanW@my-dejanews.com
Date: 1998/12/25 Raw View
In article <75rb3e$rf8$1@engnews2.Eng.Sun.COM>,
stephen.clamage@sun.com (Steve Clamage) wrote:
>
> jim.hyslop@leitch.com writes:
>
> >In article <75p24l$83j$1@engnews2.Eng.Sun.COM>,
> > stephen.clamage@sun.com (Steve Clamage) wrote:
> >[snip]
> >> You are making this much too difficult. Section 1.9 of the standard
> >> describes the sequence points in C++. Where you have an instance of
> >> a built-in operator && or ||, for example, there is a sequence point
> >> after the evaluation of the left-hand operand. Nothing more needs to
> >> be said.
>
> >But more *does* need to be said - the Standard talks about sequence points
> >when you have the simple case of one operator per statement, such as A || B,
> >but not when you have multiple operators in one statement (not an
> >unreasonable thing to do in your code). That's what I was trying to clarify.
>
> I still don't see your problem. Suppose you write a function
> that happens not be called during a program run. Are you worried
> about the sequence points inside that function? If so, why? If
> not, how is that situation different from the case of unevaluated
> sub-expressions?
>
> A sequence point is a place in the program at which all prior
> side effects must be complete. If between two sequence points
> no code is executed, then the side effects (none) are certainly
> complete.
We talk about sequence points providing us with safety. Consider
the case where p is a pointer, and the expression reads
(p && p = p->next)
Here we're counting on the sequence point to make the expression
legal, even when p is null.
I think jim's confusion may have been the fact that these
sequence points can occur within sub-expressions which themselves
do not have sequence points. For instance:
((p && p=p->next) ? 3 : 5) - ((q && q=q->next) ? 1 : 4)
-------------------------- --------------------------
<<< The left group >>> <<< The right group >>>
The left group has well-defined sequence points, and so does the
right group. But which group is evaluated first? A naive reader
might assume that since the && in the left group has a sequence
point, it must be evaluated before the right group. But of course
this is incorrect. As you pointed out, at sequence points all
prior side effects that have started must be complete -- but at
the sequence point within the left group, it is undefined if
side-effects from the right group have started or not.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/12/25 Raw View
Francis Glassborow <francis@robinton.demon.co.uk> writes:
>In article <75rb3e$rf8$1@engnews2.Eng.Sun.COM>, Steve Clamage
><stephen.clamage@sun.com> writes
>>A sequence point is a place in the program at which all prior
>>side effects must be complete. If between two sequence points
>>no code is executed, then the side effects (none) are certainly
>>complete.
>Steve, I think what he is hunting for is something like this (horrible
>code but its the simples I can come up with that demonstrates the
>problem:
>int i=1, j=2, k=3, m=5;
>int n;
>n= (j=4, i=k) + (m=k, k=i);
>The left and right subexpressions of + may be evaluated in any order.
>There are sequence points after each ',' but they do not seem to help
>with determing the value of n.
The last statement is true, because the example has undefined
behavior. Each of i and k is both accessed and modifed
without an intervening sequence point. Access is ok only
to find the value to be modified, as in (i=i+1), which is
not the case here.
The side effect of j=4 must be complete before i=k is evaluated,
and the side effect of m=k must be complete before k=i is evaluated.
But there is no sequence point between the expressions i=k and k=i.
--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/12/25 Raw View
jim.hyslop@leitch.com writes:
>In article <75rb3e$rf8$1@engnews2.Eng.Sun.COM>,
> stephen.clamage@sun.com (Steve Clamage) wrote:
>[snip]
>> I still don't see your problem. Suppose you write a function
>> that happens not be called during a program run. Are you worried
>> about the sequence points inside that function? If so, why? If
>> not, how is that situation different from the case of unevaluated
>> sub-expressions?
>I'm just trying to get a handle on sequence points, to make sure I understand
>them properly - when they occur, etc. That's all. I hope you'll agree that
>it's important to know where the sequence points will occur, so your program
>always behaves the way you expect it to.
Yes, I certainly agree with that.
Evidently I misunderstood your original questions. It seemed to
me that you were saying (I hate "I thought you said" dialogs,
but I'll press on anyway) that the standard did not
adequately describe the semantics of expressions like
A || B && C
My comment "nothing more needs to be said" applied to the standard,
which I believe is complete and unambiguous on this point, although
terse.
If instead you were asking for a tutorial, then lots more needs to
be said. :-)
If you still have specific questions about sequence points, this
newsgroup is a good place to ask them. I and others will be happy
to answer them.
--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/12/25 Raw View
In article <75v1v6$1fq$1@engnews2.Eng.Sun.COM>, Steve Clamage
<stephen.clamage@sun.com> writes
>
>Francis Glassborow <francis@robinton.demon.co.uk> writes:
>
>>In article <75rb3e$rf8$1@engnews2.Eng.Sun.COM>, Steve Clamage
>><stephen.clamage@sun.com> writes
>>>A sequence point is a place in the program at which all prior
>>>side effects must be complete. If between two sequence points
>>>no code is executed, then the side effects (none) are certainly
>>>complete.
>
>>Steve, I think what he is hunting for is something like this (horrible
>>code but its the simples I can come up with that demonstrates the
>>problem:
>
>>int i=1, j=2, k=3, m=5;
>>int n;
>
>>n= (j=4, i=k) + (m=k, k=i);
>
>>The left and right subexpressions of + may be evaluated in any order.
>>There are sequence points after each ',' but they do not seem to help
>>with determing the value of n.
>
>The last statement is true, because the example has undefined
>behavior. Each of i and k is both accessed and modifed
>without an intervening sequence point. Access is ok only
>to find the value to be modified, as in (i=i+1), which is
>not the case here.
>
>The side effect of j=4 must be complete before i=k is evaluated,
>and the side effect of m=k must be complete before k=i is evaluated.
>But there is no sequence point between the expressions i=k and k=i.
And that is the point that confuses many, whether or not you have
undefined behaviour depends on the unspecified order of evaluation of
the operands to +. Many believe (wrongly) that sequence points are
completely ordered and my example was to demonstrate they were not and
that the result can be undefined behaviour
Francis Glassborow Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@localhost.localdomain.COM (Siemel Naran)
Date: 1998/12/19 Raw View
On 18 Dec 1998 15:53:17 GMT, AllanW@my-dejanews.com
> jim.hyslop@leitch.com wrote:
>> OY!!!! How complicated can you get?
>> 1) Don't overload operator || or operator && (see Meyers, "Effective C++" -
>> or is that one in "More Effective C++"? - for a detailed explanation why)
>>
>> That cuts out most of the stuff above, and leaves you with operator || and
>> op&& for built-in types, the rule for which is simple:
>
>Doesn't really belong as part of a summary, does it? comp.std.c++
>deals with standards issues. As such, it can't afford to talk
>about programs written according to Meyers -- it has to work
>with programs according to everyone else, too. And some of those
>everyone else's do things that you and I have never even thought
>about NOT doing, that's how far different they are.
Not fair. This message was crossposted to comp.lang.c++ and
comp.std.c++.
Also, guidelines about how to use a language might lead to
technical questions about the language. For example, I often
want to initialize a Derived class this way
Derived(Base(1,2),3);
but the Base class is pure abstract. So I suggested that we
able to create unnamed abstract classes. Perhaps my
reasoning is not that appropriate to operator||, but ...
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ 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 ]
Author: walke751.NOSPAM@concentric.net (Daryle Walker)
Date: 1998/12/16 Raw View
In article <3675FB04.363A624B@xroads.com>, David Wieringa
<wieringa@xroads.com> wrote:
>In a recent code walk-thru at work, someone suggested that different
>compilers process logical OR's differently.
>
>e.g. In the code "if( x || y || z) { ... }", you can't be guarantee
>that x will be evaluated before y or z.
>
>They didn't disagree that if the first (or second) expression evaluated
>to true that the compiler would ignore the remaining expressions.
>
>Can someone solve this disagreement?
>
>According to my C++ book (Bjarne's The C++ Programming Language), it
>states that all but a few operators are left-associative. I take this
>to mean that || is included and that multiple ||'s will be executed from
>left to right.
>
>True? or compiler dependent?
>
>If so, can we assume that the compiler will stop evaluating expressions
>at the first "true" it finds? (since any true of an OR expression
>results in a true result)
>
>BTW, we're using Sun's CC 4.2 C++ compiler.
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/12/16 Raw View
Daryle Walker wrote:
>
> In article <3675FB04.363A624B@xroads.com>, David Wieringa
> <wieringa@xroads.com> wrote:
>
> >In a recent code walk-thru at work, someone suggested that different
> >compilers process logical OR's differently.
> >
> >e.g. In the code "if( x || y || z) { ... }", you can't be guarantee
> >that x will be evaluated before y or z.
> >
> >They didn't disagree that if the first (or second) expression evaluated
> >to true that the compiler would ignore the remaining expressions.
> >
> >Can someone solve this disagreement?
> >
> >According to my C++ book (Bjarne's The C++ Programming Language), it
> >states that all but a few operators are left-associative. I take this
> >to mean that || is included and that multiple ||'s will be executed from
> >left to right.
> >
> >True? or compiler dependent?
> >
> >If so, can we assume that the compiler will stop evaluating expressions
> >at the first "true" it finds? (since any true of an OR expression
> >results in a true result)
> >
> >BTW, we're using Sun's CC 4.2 C++ compiler.
>
> From previous posts here, others indicate that operator|| has some special
> ordering properties. Here is what I think a summary of these could be:
>
> 1. "x || y || z" is always treated as "(x || y) || z" due to
> assocativity. (Precedence doesn't factor in, contrary to the subject,
> since the two operators are the same.)
>
> 2. operator|| defines a "sequence point" such that stuff needed to form
> the left operand is always done before stuff needed to form the right
> operand (operator&& and operator, do this too).
>
> 3. x is always evaluated before y (if y is evaluated at all, see later points).
This is part of the behaviour of a sequence point. So add it to 2.
>
> 4. If the first operator|| is the built-in one, x is evaluated and
> "bool(x)" is found (if x wasn't already a bool). Then if "bool(x)" is
> "true", "true" is returned without ever evaluating y. If "bool(x)" is
> "false" instead, y is evaluated and "bool(y)" is found (if y wasn't
> already a bool). If both x and y were evalutated, then the expected
> result of "bool(x)" OR'd with "bool(y)" is returned.
>
> 5. If the first operator|| is an user-defined one, x is evaluated and
> possibly converted to a compatible type, then y is evaluated and possibly
> converted to a compatible type, then operator|| is applied.
If the first operator|| is user-defined, it's an ordinary
function call and the rules 1-3 don't apply. Especially there's
no sequence point, and x and y may be evaluated in any order.
This also means that if both x and x modify the same value,
the behaviour is undefined.
Example:
int a;
f(a++)||a++;
If the builtin operator|| is used, the behaviour is well defined
and a is incremented either once or twice, depending on the result
of f. If a user-defined operator|| is used (possible if f returns
a class type), the behaviour is undefined (a is modified twice
without a sequence point in between).
[...]
[ 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 ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1998/12/16 Raw View
In article <walke751.NOSPAM-1512982125030001@ts002d44.nor-
ct.concentric.net>, Daryle Walker <walke751.NOSPAM@concentric.net>
writes
>1. "x || y || z" is always treated as "(x || y) || z" due to
>assocativity. (Precedence doesn't factor in, contrary to the subject,
>since the two operators are the same.)
I do not think it matters, treat it as x || (y || z) and because of the
requirement that the left operand is strictly evaluated first and the
right operand only evaluated if the result is still indeterminate and
you reach exactly the same conclusions.
Francis Glassborow Chair of Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/12/16 Raw View
> 5. If the first operator|| is an user-defined one, x is evaluated and
> possibly converted to a compatible type, then y is evaluated and possibly
> converted to a compatible type, then operator|| is applied.
No, the order isn't garantied. In this case, || acts as
a normal function call.
I am not sure about operator|| (true, 1./0)
--
Valentin Bonnard mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
[ 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 ]
Author: AllanW@my-dejanews.com
Date: 1998/12/16 Raw View
In article <walke751.NOSPAM-1512982125030001@ts002d44.nor-ct.concentric.net>,
walke751.NOSPAM@concentric.net (Daryle Walker) wrote:
> From previous posts here, others indicate that operator|| has some special
> ordering properties. Here is what I think a summary of these could be:
>
> 1. "x || y || z" is always treated as "(x || y) || z" due to
> assocativity. (Precedence doesn't factor in, contrary to the subject,
> since the two operators are the same.)
>
> 2. operator|| defines a "sequence point" such that stuff needed to form
> the left operand is always done before stuff needed to form the right
> operand (operator&& and operator, do this too).
This is true for built-in operator||, but not for user-defined
operator||.
> 3. x is always evaluated before y (if y is evaluated at all, see later
points).
Again, true for built-in operator|| only.
> 4. If the first operator|| is the built-in one, x is evaluated and
> "bool(x)" is found (if x wasn't already a bool). Then if "bool(x)" is
> "true", "true" is returned without ever evaluating y. If "bool(x)" is
> "false" instead, y is evaluated and "bool(y)" is found (if y wasn't
> already a bool). If both x and y were evalutated, then the expected
> result of "bool(x)" OR'd with "bool(y)" is returned.
>
> 5. If the first operator|| is an user-defined one, x is evaluated and
> possibly converted to a compatible type, then y is evaluated and possibly
> converted to a compatible type, then operator|| is applied.
Or possibly y is evaluated first.
> 6. Let's call the result from [4] or [5] Temp1. Note that Temp1 must be a
> bool if the built-in operator|| was used, but may be anything if an
> user-defined operator|| was used.
>
> 7. Point [3] using the second operator||, replace 'x' with 'Temp1' (which
> is "x || y") and 'y' with 'z'.
>
> 8. Point [4] using the second operator||, replace 'x' with 'Temp1' and 'y'
> with 'z'.
>
> 9. Point [5] using the second operator||, replace 'x' with 'Temp1' and 'y'
> with 'z'.
>
> 10. Point [6], replacing points [4] and [5] with [8] and [9], and
> replacing 'Temp1' with 'Temp2'.
This is getting harder and harder to follow. But I think I understand
you, and you're right except for the points mentioned above.
> 11. Temp2 is what is returned as the result of the entire expression.
> If it is going to be used in an if-statement, like David's example, then
> it may have to be converted to bool before continuing.
Yes.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: AllanW@my-dejanews.com
Date: 1998/12/16 Raw View
In article <367771F0.9B5F2B0E@physik.tu-muenchen.de>,
Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>
> Daryle Walker wrote:
> >
> > In article <3675FB04.363A624B@xroads.com>, David Wieringa
> > <wieringa@xroads.com> wrote:
> >
> > >In a recent code walk-thru at work, someone suggested that different
> > >compilers process logical OR's differently.
> > >
> > >e.g. In the code "if( x || y || z) { ... }", you can't be guarantee
> > >that x will be evaluated before y or z.
> > >
> > >They didn't disagree that if the first (or second) expression evaluated
> > >to true that the compiler would ignore the remaining expressions.
> > >
> > >Can someone solve this disagreement?
> > >
> > >According to my C++ book (Bjarne's The C++ Programming Language), it
> > >states that all but a few operators are left-associative. I take this
> > >to mean that || is included and that multiple ||'s will be executed from
> > >left to right.
> > >
> > >True? or compiler dependent?
> > >
> > >If so, can we assume that the compiler will stop evaluating expressions
> > >at the first "true" it finds? (since any true of an OR expression
> > >results in a true result)
> > >
> > >BTW, we're using Sun's CC 4.2 C++ compiler.
> >
> > From previous posts here, others indicate that operator|| has some special
> > ordering properties. Here is what I think a summary of these could be:
> >
> > 1. "x || y || z" is always treated as "(x || y) || z" due to
> > assocativity. (Precedence doesn't factor in, contrary to the subject,
> > since the two operators are the same.)
> >
> > 2. operator|| defines a "sequence point" such that stuff needed to form
> > the left operand is always done before stuff needed to form the right
> > operand (operator&& and operator, do this too).
> >
> > 3. x is always evaluated before y (if y is evaluated at all, see later
points).
>
> This is part of the behaviour of a sequence point. So add it to 2.
>
> >
> > 4. If the first operator|| is the built-in one, x is evaluated and
> > "bool(x)" is found (if x wasn't already a bool). Then if "bool(x)" is
> > "true", "true" is returned without ever evaluating y. If "bool(x)" is
> > "false" instead, y is evaluated and "bool(y)" is found (if y wasn't
> > already a bool). If both x and y were evalutated, then the expected
> > result of "bool(x)" OR'd with "bool(y)" is returned.
> >
> > 5. If the first operator|| is an user-defined one, x is evaluated and
> > possibly converted to a compatible type, then y is evaluated and possibly
> > converted to a compatible type, then operator|| is applied.
>
> If the first operator|| is user-defined, it's an ordinary
> function call and the rules 1-3 don't apply. Especially there's
> no sequence point, and x and y may be evaluated in any order.
> This also means that if both x and x modify the same value,
> the behaviour is undefined.
Rule 1 still applies. And there is still a sequence point after
both arguments are evaluated and before the call to the operator||
logic.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: jim.hyslop@leitch.com
Date: 1998/12/17 Raw View
In article <walke751.NOSPAM-1512982125030001@ts002d44.nor-ct.concentric.net>,
walke751.NOSPAM@concentric.net (Daryle Walker) wrote:
[snip]
> From previous posts here, others indicate that operator|| has some special
> ordering properties. Here is what I think a summary of these could be:
[BIG snip]
OY!!!! How complicated can you get?
OK, here's a SIMPLE summary:
1) Don't overload operator || or operator && (see Meyers, "Effective C++" -
or is that one in "More Effective C++"? - for a detailed explanation why)
That cuts out most of the stuff above, and leaves you with operator || and
op&& for built-in types, the rule for which is simple:
2) The first expression is evaluated completely. If the result of that
evaluation forces the final result (i.e. if op|| and the first result is
true, or op&& and the first result is false), then no further evaluation is
performed. That includes side effects of the second and subsequent
expressions. Repeat with each remaining expression, in order, until the
final result is obtained.
--
Jim
Note to recruitment agencies: I delete unsolicited email from
recruitment agencies without reading it, so don't even bother.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1998/12/17 Raw View
AllanW@my-dejanews.com wrote:
>
> In article <367771F0.9B5F2B0E@physik.tu-muenchen.de>,
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> >
> > Daryle Walker wrote:
> > >
> > > In article <3675FB04.363A624B@xroads.com>, David Wieringa
> > > <wieringa@xroads.com> wrote:
> > >
> > > >In a recent code walk-thru at work, someone suggested that different
> > > >compilers process logical OR's differently.
> > > >
> > > >e.g. In the code "if( x || y || z) { ... }", you can't be guarantee
> > > >that x will be evaluated before y or z.
> > > >
> > > >They didn't disagree that if the first (or second) expression evaluated
> > > >to true that the compiler would ignore the remaining expressions.
> > > >
> > > >Can someone solve this disagreement?
> > > >
> > > >According to my C++ book (Bjarne's The C++ Programming Language), it
> > > >states that all but a few operators are left-associative. I take this
> > > >to mean that || is included and that multiple ||'s will be executed from
> > > >left to right.
> > > >
> > > >True? or compiler dependent?
> > > >
> > > >If so, can we assume that the compiler will stop evaluating expressions
> > > >at the first "true" it finds? (since any true of an OR expression
> > > >results in a true result)
> > > >
> > > >BTW, we're using Sun's CC 4.2 C++ compiler.
> > >
> > > From previous posts here, others indicate that operator|| has some special
> > > ordering properties. Here is what I think a summary of these could be:
> > >
> > > 1. "x || y || z" is always treated as "(x || y) || z" due to
> > > assocativity. (Precedence doesn't factor in, contrary to the subject,
> > > since the two operators are the same.)
> > >
> > > 2. operator|| defines a "sequence point" such that stuff needed to form
> > > the left operand is always done before stuff needed to form the right
> > > operand (operator&& and operator, do this too).
> > >
[...]
> > > 5. If the first operator|| is an user-defined one, x is evaluated and
> > > possibly converted to a compatible type, then y is evaluated and possibly
> > > converted to a compatible type, then operator|| is applied.
> >
> > If the first operator|| is user-defined, it's an ordinary
> > function call and the rules 1-3 don't apply. Especially there's
> > no sequence point, and x and y may be evaluated in any order.
> > This also means that if both x and x modify the same value,
> > the behaviour is undefined.
>
> Rule 1 still applies.
Ok, a mistake by me. Should be rules 2-3. I didn't look
carefully enough.
> And there is still a sequence point after
> both arguments are evaluated and before the call to the operator||
> logic.
True, I should have formulated more carefully. But the point
is the missing sequence point between calculation of x and y.
The sequence point from rule 2 disappears.
One can sum up the semantics quite easily:
built-in operator||: a||b is a?true:bool(b)
user defined operator||: a||b is operator||(a,b)
or a.operator||(b)
[ 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 ]
Author: AllanW@my-dejanews.com
Date: 1998/12/18 Raw View
In article <75b5b7$n5f$1@nnrp1.dejanews.com>,
jim.hyslop@leitch.com wrote:
>
> In article <walke751.NOSPAM-1512982125030001@ts002d44.nor-ct.concentric.net>,
> walke751.NOSPAM@concentric.net (Daryle Walker) wrote:
> [snip]
> > From previous posts here, others indicate that operator|| has some special
> > ordering properties. Here is what I think a summary of these could be:
> [BIG snip]
> OY!!!! How complicated can you get?
With a tiny bit of effort, we can get much more complicated than
anything you've seen so far on this thread.
> OK, here's a SIMPLE summary:
>
> 1) Don't overload operator || or operator && (see Meyers, "Effective C++" -
> or is that one in "More Effective C++"? - for a detailed explanation why)
>
> That cuts out most of the stuff above, and leaves you with operator || and
> op&& for built-in types, the rule for which is simple:
Doesn't really belong as part of a summary, does it? comp.std.c++
deals with standards issues. As such, it can't afford to talk
about programs written according to Meyers -- it has to work
with programs according to everyone else, too. And some of those
everyone else's do things that you and I have never even thought
about NOT doing, that's how far different they are.
> 2) The first expression is evaluated completely. If the result of that
> evaluation forces the final result (i.e. if op|| and the first result is
> true, or op&& and the first result is false), then no further evaluation is
> performed. That includes side effects of the second and subsequent
> expressions. Repeat with each remaining expression, in order, until the
> final result is obtained.
Even if we accept your premise in 1), this is still not sufficient.
Since it mentions both operator|| and operator&&, it implies that
it works even when they are mixed. But this is not true; operator&&
has higher precedence.
--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
[ 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 ]
Author: "Seth Jones" <seth@kansmen.com>
Date: 1998/12/15 Raw View
David Wieringa wrote in message <3675FB04.363A624B@xroads.com>...
>
>In a recent code walk-thru at work, someone suggested that different
>compilers process logical OR's differently.
>
>e.g. In the code "if( x || y || z) { ... }", you can't be guarantee
>that x will be evaluated before y or z.
>
>They didn't disagree that if the first (or second) expression evaluated
>to true that the compiler would ignore the remaining expressions.
>
>Can someone solve this disagreement?
>
>According to my C++ book (Bjarne's The C++ Programming Language), it
>states that all but a few operators are left-associative. I take this
>to mean that || is included and that multiple ||'s will be executed from
>left to right.
>
>True? or compiler dependent?
Your interpretation here is wrong. Left-associative refers to how operands
are grouped,
not the order of evaluation. For example, x / y / z will be evaluated as ( x
/ y ) / z,
not x / ( y / z ) (to pick an example where it makes a difference) BUT x, y
and z may be
evaluated in any order.
>If so, can we assume that the compiler will stop evaluating expressions
>at the first "true" it finds? (since any true of an OR expression
>results in a true result)
>
Maybe, but not because || is left-associative. Rather, || and &&, unlike
most operators,
DO guarantee that their operands are evaluated from left to right. Finally,
|| and && are short-
circuited FOR BUILT-IN TYPES. That is what prevents the right operand from
being evaluated
if the outcome of the operation is already known. If you have the 3rd
edition of Stroustrup,
this is covered in section 6.2.2
Seth Jones
[ 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 ]