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

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

| vs || operator on C99 bool types

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

Contents

  | vs || operator on C99 bool types Matthias Arndt <marndt@asmsoftware.de> - 2011-06-27 16:21 +0000
    Re: | vs || operator on C99 bool types Shao Miller <sha0.miller@gmail.com> - 2011-06-27 13:38 -0400
    Re: | vs || operator on C99 bool types Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-27 21:51 -0400
      Re: | vs || operator on C99 bool types James Waldby <not@valid.invalid> - 2011-06-28 16:16 +0000
        [OT] Genderangement [Was: Re: | vs || operator on C99 bool types] Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-28 20:35 -0400
          Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types] blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-29 21:33 +0000
            Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types] Michael Press <rubrum@pacbell.net> - 2011-06-30 10:58 -0700
              Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types] blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-06-30 18:57 +0000
                Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types] Michael Press <rubrum@pacbell.net> - 2011-07-01 12:53 -0700
                  Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types] blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-02 18:27 +0000
                    Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types] Michael Press <rubrum@pacbell.net> - 2011-07-03 20:53 -0700
        Re: | vs || operator on C99 bool types Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-03 03:34 -0700
          Re: | vs || operator on C99 bool types James Kuyper <jameskuyper@verizon.net> - 2011-07-03 08:25 -0400
            Re: | vs || operator on C99 bool types gordonb.pbl6v@burditt.org (Gordon Burditt) - 2011-07-03 18:23 -0500
    Re: | vs || operator on C99 bool types James Kuyper <jameskuyper@verizon.net> - 2011-06-28 07:21 -0400
      Re: | vs || operator on C99 bool types James Kuyper <jameskuyper@verizon.net> - 2011-06-28 08:24 -0400
        Re: | vs || operator on C99 bool types Matthias Arndt <marndt@asmsoftware.de> - 2011-06-28 16:11 +0000
    Re: | vs || operator on C99 bool types Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-28 16:37 -0700
      Re: | vs || operator on C99 bool types Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-03 03:41 -0700
        Re: | vs || operator on C99 bool types Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-03 15:02 -0700

#7080 — | vs || operator on C99 bool types

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/marndt.asc
Jabber: simonsunnyboy@atari-jabber.org

[toc] | [next] | [standalone]

#7085

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.

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

#7115

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

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

#7148

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

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

#7176 — [OT] Genderangement [Was: Re: | vs || operator on C99 bool types]

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

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

#7248 — Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types]

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.

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

#7310 — Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types]

In article <971k1mF5gbU4@mid.individual.net>,
 blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:

> 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?" ?

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

-- 
Michael Press

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

#7315 — Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types]

In article <rubrum-BDFD75.10580530062011@news.albasani.net>,
Michael Press  <rubrum@pacbell.net> wrote:
> In article <971k1mF5gbU4@mid.individual.net>,
>  blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:
> 
> > 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?" ?
> 
> 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.

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

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

#7386 — Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types]

In article <973v8pFgd2U1@mid.individual.net>,
 blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:

> In article <rubrum-BDFD75.10580530062011@news.albasani.net>,
> Michael Press  <rubrum@pacbell.net> wrote:
> > In article <971k1mF5gbU4@mid.individual.net>,
> >  blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:
> > 
> > > 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?" ?
> > 
> > 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.

-- 
Michael Press

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

#7469 — Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types]

In article <rubrum-1A1C0A.12535101072011@news.albasani.net>,
Michael Press  <rubrum@pacbell.net> wrote:
> In article <973v8pFgd2U1@mid.individual.net>,
>  blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:
> 
> > In article <rubrum-BDFD75.10580530062011@news.albasani.net>,
> > Michael Press  <rubrum@pacbell.net> wrote:
> > > In article <971k1mF5gbU4@mid.individual.net>,
> > >  blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:

[ snip ]

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

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

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

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!

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

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

#7559 — Re: [OT] Genderangement [Was: Re: | vs || operator on C99 bool types]

In article <97967kFoijU2@mid.individual.net>,
 blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:

> In article <rubrum-1A1C0A.12535101072011@news.albasani.net>,
> Michael Press  <rubrum@pacbell.net> wrote:
> > In article <973v8pFgd2U1@mid.individual.net>,
> >  blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:
> > 
> > > In article <rubrum-BDFD75.10580530062011@news.albasani.net>,
> > > Michael Press  <rubrum@pacbell.net> wrote:
> > > > In article <971k1mF5gbU4@mid.individual.net>,
> > > >  blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:
> 
> [ snip ]
> 
> > > > > > > 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. :)
> 
> Okay.  I think in writing the initial post I thought about putting
> in a :-) at that point but decided not to.  Maybe next time!
> 
> > > 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.
> 
> 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.

-- 
Michael Press

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

#7495

On Jun 28, 5:16 pm, James Waldby <n...@valid.invalid> 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
> >> _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.

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.

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

#7497

On 07/03/2011 06:34 AM, Nick Keighley wrote:
> On Jun 28, 5:16�pm, James Waldby <n...@valid.invalid> wrote:
>> On Mon, 27 Jun 2011 21:51:20 -0400, Eric Sosman wrote:
...
>>> 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.

[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]
-- 
James Kuyper

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

#7538

> 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

Since it hasn't yet come up with a replacement, it's hard to take it
seriously as a standard.

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

Little recognized is the problem that the pronouns are also speciesist.

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

I propose s/h/it to avoid the implication that an intelligent being
has to have gender.  It's easy to pronounce.  For some reason it
hasn't caught on much.

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

#7132

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

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

#7137

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

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

#7147

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

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

#7170

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.

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

#7496

On Jun 29, 12:37 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Matthias Arndt <mar...@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.

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.

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

#7532

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On Jun 29, 12:37 am, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> Matthias Arndt <mar...@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.
>
> 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.

[toc] | [prev] | [standalone]

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

csiph-web