[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

| vs || operator on C99 bool types

Matthias Arndt

6/27/2011 4:21:00 PM

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
--
Matthias Arndt <marndt@asmsoftware.de>
PGP-Key: http://www.final-memory.org/files/...
Jabber: simonsunnyboy@atari-jabber.org

18 Answers

ram

6/27/2011 5:37:00 PM

0

Matthias Arndt <marndt@asmsoftware.de> writes:
>_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

6/27/2011 5:38:00 PM

0

On 6/27/2011 12:21, Matthias Arndt wrote:
> 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

6/28/2011 1:51:00 AM

0

On 6/27/2011 12:21 PM, Matthias Arndt wrote:
> 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.

--
Eric Sosman
esosman@ieee-dot-org.invalid

James Kuyper

6/28/2011 11:21:00 AM

0

On 06/27/2011 12:21 PM, Matthias Arndt wrote:
> 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

James Kuyper

6/28/2011 12:25:00 PM

0

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.
--
James Kuyper

Matthias Arndt

6/28/2011 4:11:00 PM

0

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/... 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
--
Matthias Arndt <marndt@asmsoftware.de>
PGP-Key: http://www.final-memory.org/files/...
Jabber: simonsunnyboy@atari-jabber.org

Not

6/28/2011 4:16:00 PM

0

On Mon, 27 Jun 2011 21:51:20 -0400, Eric Sosman wrote:
> On 6/27/2011 12:21 PM, Matthias Arndt wrote:
>> 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.

--
jiw

Tim Rentsch

6/28/2011 11:38:00 PM

0

Matthias Arndt <marndt@asmsoftware.de> writes:

> 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

6/29/2011 12:36:00 AM

0

On 6/28/2011 12:16 PM, James Waldby wrote:
> On Mon, 27 Jun 2011 21:51:20 -0400, Eric Sosman wrote:
>> On 6/27/2011 12:21 PM, Matthias Arndt wrote:
>>> 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) ;-)

--
Eric Sosman
esosman@ieee-dot-org.invalid

blmblm@myrealbox.com

6/29/2011 9:34:00 PM

0

In article <iuds1r$6fd$1@dont-email.me>,
Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
> On 6/28/2011 12:16 PM, James Waldby wrote:
> > On Mon, 27 Jun 2011 21:51:20 -0400, Eric Sosman wrote:
> >> On 6/27/2011 12: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?" ?

> 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.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.