| vs || operator on C99 bool types

[Matthias Arndt]

Hello all,

I heard an opinion on the use of the | operator together with C99
conform bool types (stdbool.h)

My discussion partner stated that
_Bool a, b;
.......
a | b;

should be forbidden and a || b should be used instead.

I personally can't see the difference for true boolean types (which
would be *implementation* specific, but let's assume an embedded
compiler with a true bool type that maps to a real bit.)

What does the standard say? Are there opinions on this?

I personally have no true opinion on this, otherwise I wouldn't open
this up for discussion.

Best regards,
Matthias

 

[Stefan Ram]

_Bool a, b;
......
a | b;
should be forbidden and a || b should be used instead.
I personally can't see the difference

The lines »

_Bool a, b;
.......
a | b;

« are only allowed within a comment, while »a || b« can be
used as an expression. Whether one of them is correct,
depends on the requirements and the context.

 

[Shao Miller]

Hello all,

I heard an opinion on the use of the | operator together with C99
conform bool types (stdbool.h)

My discussion partner stated that
_Bool a, b;
......
a | b;

should be forbidden and a || b should be used instead.

Forbidden? "... The rank of _Bool shall be less than the rank of all
other standard integer types. ..."[6.3.1.1p1] That is a discussion
which concludes with the definition of "the integer promotions."

Then we have for '|'[6.5.12p3] that the "usual arithmetic conversions"
are performed, which in this case includes the integer
promotions[6.3.1.8p1]. So using '_Bool' doesn't appear to be forbidden.

Perhaps your discussion partner believes that the construct "ought to
be" ("should be" makes me think that something "is already true," given
some reference) because any non-value bits in a '_Bool' are not very
useful in a program.

I personally can't see the difference for true boolean types (which
would be *implementation* specific, but let's assume an embedded
compiler with a true bool type that maps to a real bit.)

What does the standard say? Are there opinions on this?

I personally have no true opinion on this, otherwise I wouldn't open
this up for discussion.

However the value is stored, it undergoes the integer promotions and is
not longer a '_Bool' by the time it's used in the context you provide,
as far as I understand it.

 

[Eric Sosman]

Hello all,

I heard an opinion on the use of the | operator together with C99
conform bool types (stdbool.h)

My discussion partner stated that
_Bool a, b;
......
a | b;

should be forbidden and a || b should be used instead.

The only effective difference that I can see is that with | both
`a' and `b' are evaluated, while with || the evaluation of `b' is
skipped if `a' evaluates to non-zero. In your example, neither `a'
nor `b' has side-effects, and the evaluation of `b' does not depend
on the truth of `a', so I see no effective difference.

Perhaps your discussion partner could favor us with the reasons
behind his assertion? I'm sure he has some, and perhaps they'll be
convincing. But on the bald evidence of the example at hand, I'd
have to dismiss his preference as superstition.

I personally can't see the difference for true boolean types (which
would be *implementation* specific, but let's assume an embedded
compiler with a true bool type that maps to a real bit.)

You said "C99," did you not? The actual number of bits occupied
by a `_Bool' is at the implementation's whim, of course -- it must
be at least CHAR_BIT and could be much greater -- but choosing |
over || or vice versa wouldn't change it.

A guess: Perhaps your discussion partner retains bad memories
of a "simulated boolean" from pre-C99 days, and was really concerned
with & vs. &&? With a SimulatedBool based on an integer type, you
could have

SimulatedBool a = 1, b = 2; /* both "true" */
assert (a && b); /* succeeds */
assert (a & b); /* fails */

With actual _Bool instead of SimulatedBool both assertions would
succeed. Is that the origin of his prejudice?

What does the standard say? Are there opinions on this?

The standard says -- well, the Standard says a lot. The pieces
that seem relevant are those I've summarized above. If others are
of importance to your discussion partner, try to elicit them.

 

[James Kuyper]

Hello all,

I heard an opinion on the use of the | operator together with C99
conform bool types (stdbool.h)

My discussion partner stated that
_Bool a, b;
......
a | b;

should be forbidden and a || b should be used instead.

I personally can't see the difference for true boolean types (which
would be *implementation* specific, but let's assume an embedded
compiler with a true bool type that maps to a real bit.)

His assertion that it "should be forbidden" is somewhat ambiguous. If
he's suggesting that you should be forbidden to write that, because it
is not permitted in C99, he's wrong. However, he could also be
suggesting that, while it is currently permitted, it should not be.

If so, then he might be talking about the idea, which has frequently
been discussed, that it was a mistake for C to conflate arithmetic and
boolean values the way that it does. I tend to agree, but it's not
feasible to change that aspect of C without breaking a LOT of code
(including most of mine: since C does conflate them, I make heavy use of
that fact in my code).

To make this idea clearer, let me outline how a new C-like language that
implemented this idea would differ from C:
* in C, _Bool is a standard unsigned integer type. As such, it is also a
member of the several other type categories: "unsigned", "standard",
"integer", "basic", "real", "arithmetic", "scalar", and "object". In
this new language, _Bool would only be a member of the last two of those
type categories.
* All relational and equality comparisons result in a _Bool value, even
in #if expressions.
* All of the following are constrained to be of type _Bool:
- The operands of all logical operators (!, &&, ||)
- The first operand of ?:
- The condition in if(), while() and do while() statements
- The condition in #if directives.
* There are no conversions, implicit or explicit, permitted between
_Bool and other types. The equivalent of converting scalar_value to
_Bool can be performed by "scalar_value==0", and the equivalent of
conversion from _Bool can be performed by "boolean_value ? 1 : 0".
* Values of type _Bool are not implicitly promoted to 'int'.

In such a language, a|b would be an error, because bitwise-or requires
that it's operands have integer type. If you actually needed to express
the same idea, you could write (a?1:0)|(b?1:0), or (a||b)?1:0. Yes,
those expressions are clumsier - but that's precisely the point: the
increased clumsiness is supposed to make it easier for you to stop and
think "does it really make sense to do this?" - the answer will often be
"No". The idea is that things which often make sense should be easier to
write than things that do not usually make sense.

 

[James Kuyper]

On 06/28/2011 07:21 AM, James Kuyper wrote:
....

If so, then he might be talking about the idea, which has frequently
been discussed, that it was a mistake for C to conflate arithmetic and
boolean values the way that it does. I tend to agree, but it's not
feasible to change that aspect of C without breaking a LOT of code
(including most of mine: since C does conflate them, I make heavy use of
that fact in my code).

To make this idea clearer, let me outline how a new C-like language that
implemented this idea would differ from C: ....
* All relational and equality comparisons result in a _Bool value, even
in #if expressions.
* All of the following are constrained to be of type _Bool:
- The operands of all logical operators (!, &&, ||)

I should also have specified that the results of logical operators are
of type _Bool.

 

[Matthias Arndt]

Hello together,

thanks for your valuable input. I've invited my discussion partner, Henk
Robbers, to read this discussion as well and I hope he will contribute.

He is actually maintaining his own C
compiler at http://members.chello.nl/h.robbers/ which is intended for
Atari ST and compatible computers, including support for Coldfire
processors.

What I now take from this is that true boolean evaluations should not be
enforced or old stuff breaks. The standard tries to be backwards
compatible.

Best regards,
Matthias

 

[James Waldby]

I heard an opinion on the use of the | operator together with C99
conform bool types (stdbool.h)

My discussion partner stated that
_Bool a, b;
......
a | b;

should be forbidden and a || b should be used instead.

The only effective difference that I can see is that with | both
`a' and `b' are evaluated, while with || the evaluation of `b' is
skipped if `a' evaluates to non-zero. In your example, neither `a' nor
`b' has side-effects, and the evaluation of `b' does not depend on the
truth of `a', so I see no effective difference.

Perhaps your discussion partner could favor us with the reasons
behind his assertion? I'm sure he has some, and perhaps they'll be
convincing. But on the bald evidence of the example at hand, I'd have
to dismiss his preference as superstition. [snip 3 para.]
With actual _Bool instead of SimulatedBool both assertions would
succeed. Is that the origin of his prejudice?

E.S., I agree with your comments except for a minor quibble:
there's no evidence in OP that pronouns 'he' and 'his' apply.

 

[Tim Rentsch]

Hello all,

I heard an opinion on the use of the | operator together with C99
conform bool types (stdbool.h)

My discussion partner stated that
_Bool a, b;
......
a | b;

should be forbidden and a || b should be used instead.

I personally can't see the difference for true boolean types (which
would be *implementation* specific, but let's assume an embedded
compiler with a true bool type that maps to a real bit.) [snip]

If I may make a suggestion --

Write up a list of reasons (as many as you can think of) for
why 'a && b' is preferable to 'a & b', and also a list for
why 'a & b' is preferable to 'a && b', and circumstances
under which it would be better to use one or the other.

After these have been assembled, present them to your
discussion partner, and ask him (or her) which ones he
agrees with, which ones he disagrees with, how important
they are, and whether any have been left out.

I think a case can be made that neither form is "best"
in all circumstances, so which one should be used would
depend on where and how the use would occur. Having said
that, the important thing here is not just to reach a
good decision about what to do, but to understand more
specifically what your discussion partner thinks and why.
Reviewing the plus/minus lists together will do that.

 

[Eric Sosman]

I heard an opinion on the use of the | operator together with C99
conform bool types (stdbool.h)

My discussion partner stated that
[...]

Perhaps your discussion partner could favor us with the reasons
behind his assertion? [...]

E.S., I agree with your comments except for a minor quibble:
there's no evidence in OP that pronouns 'he' and 'his' apply.

1) I'll stand by them, on the grounds that only a male could
be so foolhardy.

2) Sorry about your P.M.S., James. Better luck next month.

3) ;-)

 

[blmblm]

[ snip ]

Perhaps your discussion partner could favor us with the reasons
behind his assertion? [...]

E.S., I agree with your comments except for a minor quibble:
there's no evidence in OP that pronouns 'he' and 'his' apply.

1) I'll stand by them, on the grounds that only a male could
be so foolhardy.

Defending yourself from an implied charge of gender bias by using
gender stereotypes .... "What's wrong with this picture?" ?

2) Sorry about your P.M.S., James. Better luck next month.

Aren't we all old people who don't have that problem anyway ....

3) ;-)

What you said.

 

[blmblm]

On 6/28/2011 12:16 PM, James Waldby wrote:
21 PM, Matthias Arndt wrote:

[ snip ]

Perhaps your discussion partner could favor us with the reasons
behind his assertion? [...]

E.S., I agree with your comments except for a minor quibble:
there's no evidence in OP that pronouns 'he' and 'his' apply.

1) I'll stand by them, on the grounds that only a male could
be so foolhardy.

Defending yourself from an implied charge of gender bias by using
gender stereotypes .... "What's wrong with this picture?" ?

Nothing. It was funny; but I did not expect you to find it so.

Ah, but I did, at least mildly so. Perhaps what I said at the end
of my post (not quoted) -- a "what you said" in response to Eric's
"" -- didn't make that clear.

Just sayin', not trying to be argumentative, but mildly curious about
how you come into the discussion.

 

[Michael Press]

21 PM, Matthias Arndt wrote:

[ snip ]

Perhaps your discussion partner could favor us with the reasons
behind his assertion? [...]

E.S., I agree with your comments except for a minor quibble:
there's no evidence in OP that pronouns 'he' and 'his' apply.

1) I'll stand by them, on the grounds that only a male could
be so foolhardy.

Defending yourself from an implied charge of gender bias by using
gender stereotypes .... "What's wrong with this picture?" ?

Nothing. It was funny; but I did not expect you to find it so.

Ah, but I did, at least mildly so. Perhaps what I said at the end
of my post (not quoted) -- a "what you said" in response to Eric's
"" -- didn't make that clear.

Not to me.

Just sayin', not trying to be argumentative, but mildly curious about
how you come into the discussion.

"What's wrong with this picture?" as an appeal to others.

 

[blmblm]

[ snip ]

Not to me.

Okay. I think in writing the initial post I thought about putting
in a at that point but decided not to. Maybe next time!

"What's wrong with this picture?" as an appeal to others.

Oh. Right. I'm not sure I meant it that way, but okay. I think
I was also somewhat puzzled by your "I did not expect you to find it
so," which seems to me to suggest that I in particular .... Not sure
how to finish that sentence. Not very important anyway!

 

[Nick Keighley]

     The only effective difference that I can see is that with | both
`a' and `b' are evaluated, while with || the evaluation of `b' is
skipped if `a' evaluates to non-zero.  In your example, neither `a' nor
`b' has side-effects, and the evaluation of `b' does not depend on the
truth of `a', so I see no effective difference.

     Perhaps your discussion partner could favor us with the reasons
behind his assertion?  I'm sure he has some, and perhaps they'll be
convincing.  But on the bald evidence of the example at hand, I'd have
to dismiss his preference as superstition. [snip 3 para.]
With actual _Bool instead of SimulatedBool both assertions would
succeed.  Is that the origin of his prejudice?

E.S., I agree with your comments except for a minor quibble:
there's no evidence in OP that pronouns 'he' and 'his' apply.

It's standard English usage to refer to someone of unknown gender as
"he". "it" is usually regarded as rude. S/he may be standard where you
are but not where I am.

 

[Nick Keighley]

Hello all,

I heard an opinion on the use of the | operator together with C99
conform bool types (stdbool.h)

My discussion partner stated that
_Bool a, b;
......
a | b;

should be forbidden and a || b should be used instead.

I personally can't see the difference for true boolean types (which
would be *implementation* specific, but let's assume an embedded
compiler with a true bool type that maps to a real bit.)   [snip]

If I may make a suggestion --

Write up a list of reasons (as many as you can think of) for
why 'a && b' is preferable to 'a & b', and also a list for
why 'a & b' is preferable to 'a && b', and circumstances
under which it would be better to use one or the other.

After these have been assembled, present them to your
discussion partner, and ask him (or her) which ones he
agrees with, which ones he disagrees with, how important
they are, and whether any have been left out.

I think a case can be made that neither form is "best"
in all circumstances, so which one should be used would
depend on where and how the use would occur.  Having said
that, the important thing here is not just to reach a
good decision about what to do, but to understand more
specifically what your discussion partner thinks and why.
Reviewing the plus/minus lists together will do that.

I think the obvious reason is that they have different semantics.
Using & may preclude the easy replacement of a variable with a
function.

if (bufferFull & LatchDown)
flushAll();

if (bufferFull() & LatchDown())
flushAll();

now we have to careful that the functions don't have side effects. And
that the Latchdown() function works even when the buffer is not full.
And that unnecessary calls to latchDown() aren't too expensive.

The rule is (in this and many other contexts) use the clearest and
most appropriate semantic form to achieve your ends.

 

[James Kuyper]

E.S., I agree with your comments except for a minor quibble:
there's no evidence in OP that pronouns 'he' and 'his' apply.

[OT]
It's standard English usage to refer to someone of unknown gender as
"he". "it" is usually regarded as rude. S/he may be standard where you
are but not where I am.

That standard is, in many contexts, giving way to a conflicting one
which rejects the use 'he' when the gender is unknown, as sexist. This
is not, as I've heard some people suggest, due to ignorance of the rule
of English that makes it technically correct. It is based in a rejection
of the idea that it is a good rule to have.

"he or she" is clumsier. Rewording the statement so that a pronoun is
not needed is a cleaner alternative, but often quite difficult; I
usually use one or the other of those two approaches.

The ideal solution would be a new pronoun which implies neither an
insulting lack of gender, nor non-existent knowledge of the correct
gender. Several have been suggested, but none has received wide
acceptance. I don't think anyone is advocating "s/he" as that new
pronoun - for one thing, it's unpronounceable.
[/OT]

 

[Tim Rentsch]

Hello all,

I heard an opinion on the use of the | operator together with C99
conform bool types (stdbool.h)

My discussion partner stated that
_Bool a, b;
......
a | b;

should be forbidden and a || b should be used instead.

I personally can't see the difference for true boolean types (which
would be *implementation* specific, but let's assume an embedded
compiler with a true bool type that maps to a real bit.) [snip]

If I may make a suggestion --

Write up a list of reasons (as many as you can think of) for
why 'a && b' is preferable to 'a & b', and also a list for
why 'a & b' is preferable to 'a && b', and circumstances
under which it would be better to use one or the other.

After these have been assembled, present them to your
discussion partner, and ask him (or her) which ones he
agrees with, which ones he disagrees with, how important
they are, and whether any have been left out.

I think a case can be made that neither form is "best"
in all circumstances, so which one should be used would
depend on where and how the use would occur. Having said
that, the important thing here is not just to reach a
good decision about what to do, but to understand more
specifically what your discussion partner thinks and why.
Reviewing the plus/minus lists together will do that.

I think the obvious reason is that they have different semantics.
Using & may preclude the easy replacement of a variable with a
function.

if (bufferFull & LatchDown)
flushAll();

if (bufferFull() & LatchDown())
flushAll();

now we have to careful that the functions don't have side effects. And
that the Latchdown() function works even when the buffer is not full.
And that unnecessary calls to latchDown() aren't too expensive.

Yes, and there are other situations where & can be preferable
to &&.

The rule is (in this and many other contexts) use the clearest and
most appropriate semantic form to achieve your ends.

There can be other relevant concerns besides readability,
but assuming for the moment that readability is paramount,
there still are the questions, one, what ends are in fact
desired, and two, which semantic form is actually clearest
(or most appropriate). People often have different opinions
on one or both of these questions, which is why it can help
to list the reasons explicitly and see where the points of
agreement or disagreement are more specifically.

 

[Michael Press]

[ snip ]

Not to me.

Okay. I think in writing the initial post I thought about putting
in a at that point but decided not to. Maybe next time!

"What's wrong with this picture?" as an appeal to others.

Oh. Right. I'm not sure I meant it that way, but okay. I think
I was also somewhat puzzled by your "I did not expect you to find it
so," which seems to me to suggest that I in particular .... Not sure
how to finish that sentence. Not very important anyway!

Quite. To be clear, through the miracle of hindsight
I see that there were enough clues for me to not have
gone off the rails as I did.