| vs || operator on C99 bool types

Discussion in 'C Programming' started by Matthias Arndt, Jun 27, 2011.

  1. 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 Arndt, Jun 27, 2011
    1. Advertisements

  2. Matthias Arndt

    Stefan Ram Guest

    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.
    Stefan Ram, Jun 27, 2011
    1. Advertisements

  3. Matthias Arndt

    Shao Miller Guest

    Forbidden? "... The rank of _Bool shall be less than the rank of all
    other standard integer types. ..."[] 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[]. 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.
    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.
    Shao Miller, Jun 27, 2011
  4. Matthias Arndt

    Eric Sosman Guest

    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.
    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?
    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, Jun 28, 2011
  5. Matthias Arndt

    James Kuyper Guest

    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, Jun 28, 2011
  6. Matthias Arndt

    James Kuyper Guest

    On 06/28/2011 07:21 AM, James Kuyper wrote:
    I should also have specified that the results of logical operators are
    of type _Bool.
    James Kuyper, Jun 28, 2011
  7. 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

    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

    Best regards,
    Matthias Arndt, Jun 28, 2011
  8. Matthias Arndt

    James Waldby Guest

    E.S., I agree with your comments except for a minor quibble:
    there's no evidence in OP that pronouns 'he' and 'his' apply.
    James Waldby, Jun 28, 2011
  9. Matthias Arndt

    Tim Rentsch Guest

    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.
    Tim Rentsch, Jun 29, 2011
  10. Matthias Arndt

    Eric Sosman Guest

    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, Jun 29, 2011
  11. Matthias Arndt

    blmblm Guest

    [ snip ]
    Defending yourself from an implied charge of gender bias by using
    gender stereotypes .... "What's wrong with this picture?" ?
    Aren't we all old people who don't have that problem anyway ....
    What you said.
    blmblm, Jun 29, 2011
  12. Matthias Arndt

    blmblm Guest

    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.
    blmblm, Jun 30, 2011
  13. Not to me. :)
    "What's wrong with this picture?" as an appeal to others.
    Michael Press, Jul 1, 2011
  14. Matthias Arndt

    blmblm Guest

    [ snip ]
    Okay. I think in writing the initial post I thought about putting
    in a :) at that point but decided not to. Maybe next time!
    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!
    blmblm, Jul 2, 2011
  15. 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, Jul 3, 2011
  16. I think the obvious reason is that they have different semantics.
    Using & may preclude the easy replacement of a variable with a

    if (bufferFull & LatchDown)

    if (bufferFull() & LatchDown())

    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.
    Nick Keighley, Jul 3, 2011
  17. Matthias Arndt

    James Kuyper Guest

    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.
    James Kuyper, Jul 3, 2011
  18. Matthias Arndt

    Tim Rentsch Guest

    Yes, and there are other situations where & can be preferable
    to &&.
    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.
    Tim Rentsch, Jul 3, 2011
  19. 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, Jul 4, 2011
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.