stdbool.h

Discussion in 'C Programming' started by Jorgen Grahn, Mar 1, 2014.

  1. Jorgen Grahn

    Jorgen Grahn Guest

    I'm sitting with a C99 code base and thinking about introducing
    <stdbool.h>, the 'bool' type and true/false. Anything special I
    have to keep in mind?

    Am I likely to end up in conflict with people who feel stdbool.h
    is an abomination? More than other C99 features, that is.

    My background is in C++ where I of course use bool a lot. In C I tend
    to use naked ints for booleans, and 0 and 1 when I need a true or
    false constant. Works well, but it's not exactly self-documenting.

    /Jorgen
     
    Jorgen Grahn, Mar 1, 2014
    #1
    1. Advertisements

  2. Jorgen Grahn

    Stefan Ram Guest

    Yes. Do not write code like

    if( isprint( ch )== true )...
     
    Stefan Ram, Mar 1, 2014
    #2
    1. Advertisements

  3. Jorgen Grahn

    Osmium Guest

    IMO adding that stuff after all these years is like putting lipstick on a
    pig.
     
    Osmium, Mar 1, 2014
    #3
  4. Jorgen Grahn

    jacob navia Guest

    Le 01/03/2014 22:37, Osmium a écrit :
    One of the characteristics of many C++ programmers is their attitude
    towards people prgramming in other languages.

    Java programmers are regularly insulted in their discussion group,
    together with C# programmers or any other programmers that do not buy
    the C++ stuff and dare program in another language.

    Of course this doesn't apply to all C++ programmers. Only to those that
    insult other people or programmint tools of course.

    It is a tradition of them, to come to this forum to "preach the good
    word", and start writing things like the sentence above.

    Well, it is a state of mind, and you eventually get used to their stuff,
    their arrogance, their absolute ignorance. It is impossible to avoid: if
    you take a lot of people you *must* have a moron among them. It is
    inevitable.
     
    jacob navia, Mar 1, 2014
    #4
  5. Jorgen Grahn

    jacob navia Guest

    Le 01/03/2014 22:10, Jorgen Grahn a écrit :
    Yes. The first thing is:

    Do not do that.


    Get a C99 compiler and it will come with a stdbool.h.

    If you write your own, name it diffeerently than stdbool.h since that is
    the name of the standard file that should come with the distribution of
    the compiler you use.
    The people that think that using "bool" is "an abomination" are not very
    bright, and you can safely ignore their opinion.
    That is why the language provides <stdbool.h> since 15 years...
     
    jacob navia, Mar 1, 2014
    #5
  6. Jorgen Grahn

    Jorgen Grahn Guest

    You misunderstand -- my intention is not to /write/ stdbool.h, just
    start /using/ it. The code is already C99.

    /Jorgen
     
    Jorgen Grahn, Mar 1, 2014
    #6
  7. Jorgen Grahn

    Jorgen Grahn Guest

    Osmium might just as well oppose anything newer than ANSI C, or this
    particular part of C99. It's the latter which interests me -- whether
    the few who use C99 also use stdbool.h. I have never seen it used,
    but I've seen people complain about the builtin name _Bool.

    /Jorgen
     
    Jorgen Grahn, Mar 1, 2014
    #7
  8. Jorgen Grahn

    Osmium Guest

    It's a cosmetic change, it adds no functionality. It violates one of the
    basic philosophies of the language, lean and mean. The barrier to changing a
    language should be higher than the barrier to controversial original
    content. It's just plain frivolous.
     
    Osmium, Mar 2, 2014
    #8
  9. Jorgen Grahn

    jacob navia Guest

    Le 02/03/2014 01:48, Osmium a écrit :
    printf("%d\n",(bool)6);

    prints

    1

    A _Bool value can have only two values. This is a new functionality that
    was added to the language by the C99 standard, and eliminates the
    problems when a boolean was represented by an integer and could have ANY
    value an integer can hold.
    So, C is no longer "mean and lean" because it supports bool?

    What a nonsense really.
    Boolean values arise everywhere you program something. It is a natural
    consequence of the boolean logic used in the circuits that build the
    computers we use. To say that "bool" is "frivolus" is completely
    nonsense, there isn't any real program that doesn't use "bool".
     
    jacob navia, Mar 2, 2014
    #9
  10. Jorgen Grahn

    Stefan Ram Guest

    !!6 is the idiom.
    This is a way to implement isupper:

    #define isupper(c) (( __ctype__ + 8 )[ c ]& _H )

    . One could surely reduce the result to the set {0,1},
    but this might take an additional processor cycle, and
    the caller might not need it. If the caller should
    need it, he is free to

    #define ISUPPER(c) (!!(isupper(c)))

    , but why pay for what one does not need?
    On other languages. In C we have int. if, while, all work
    with int.

    »God made the integers, all the rest is the work of man.«

    Leopold Kronecker
    It is a natural consequence of machine instructions like
    CBZ (Conditional Branch on Zero) and
    CBNZ (Conditional Branch on Non-Zero)
    that also care about ints, not bools.
     
    Stefan Ram, Mar 2, 2014
    #10
  11. bool breaks libraries.

    The snag is that you have, say some image-processing routines. One of them
    test whether a point is in a polygon.
    OK so that's
    bool ptinpoly(POLYGON *poly, double x, double y)

    That would be OK if bool was a built-in type. But a geometry library as no
    business exporting a boolean type to the rest of the program. If you define
    bool in any way, either you conflict with someone else, or you have bool,
    boolean, BOOL, bit, flag, logical, and bool_t all swilling around your code
    for the same thing.

    Qt suggest that people don't use boolean for parameters. Their thinking is
    that

    sd = standard_deviation(x, N, true);

    is confusing. The function obviously calculates the standard deviation, x is
    obviously the samples and N size. But does true mean population or sample
    deviation? Or is is something else entirely? Very hard to be sure.

    sd = standard_deviation(x, N, SD_POPULATION);

    is the way to go.
     
    Malcolm McLean, Mar 2, 2014
    #11
  12. Jorgen Grahn

    Ian Collins Guest

    Well it is if you use the the standard type, which was introduced to
    solve the problems you describe.
    or better still, use bool and declare

    const bool sd_population = true;

    and use that.
     
    Ian Collins, Mar 2, 2014
    #12
  13. I don't get this argument. It is an argument against improper interface
    documentation, but not against bool. Whether the argument is int or not
    does not make any difference here.

    Greetings,
    Thomas
     
    Thomas Richter, Mar 2, 2014
    #13
  14. Jorgen Grahn

    BartC Guest

    Maybe a proper 'Bit' type would be more appropriate then.

    Something more general than the 'bitfield' types in a struct, and more
    lightweight than bitstrings of your containers library. And so that in:

    Bit a[64];

    sizeof(a) would be 8 (when CHAR_BIT is 8). However they would need their own
    special kind of pointer, and a special sizeof_bits().

    By contrast, with:

    _Bool b[64];

    sizeof(b) generally gives 64.

    But a single Bit variable would have to be be the same size as a single
    _Bool (one char).
     
    BartC, Mar 2, 2014
    #14
  15. Am 02.03.2014 00:58, schrieb Jorgen Grahn:
    You should rather ask the people you are working with than a NG. I used
    to work on a embedded platform with a C compiler with partial C99
    support. Using bool there was quite common. But must people working on
    the platform had knowledge in at least another programming language so
    bool was nothing special for them. We had the innofficial rule that C99
    features which are supported when switching to C++ are allowed (bool and
    const where ok; VLAs were forbidden).

    Greetz,

    Sebastian
     
    Sebastian Doht, Mar 2, 2014
    #15
  16. Jorgen Grahn

    Jorgen Grahn Guest

    We used to, but for the past fifteen years we have also had bool.

    Seems to me C is now in the same place as C++: booleanness is still
    based on int, but when you need to store a boolean value you have the
    option to give it the type bool.

    (After having written that, I'm suddenly unsure whether 1==2 has the
    type int or bool in C++ ... the difference is minor.)

    /Jorgen
     
    Jorgen Grahn, Mar 2, 2014
    #16
  17. This is an argument against using Boolean constants as arguments, not
    about using the bool type for parameters. The parameter can have as
    descriptive a name as you like.

    But it has nothing at all to do with Boolean types at all. The same
    advice should apply to all unexplained constants in code. There is
    nothing especially mysterious about true and false any more that than
    there is about 0 or 42 or 5.6.
    That's one way to go, but there are others depending on the situation.
     
    Ben Bacarisse, Mar 2, 2014
    #17
  18. People aren't machines.

    They'll pass "true" or "false" to a function because it's already a descriptive
    identifier. They'll use bool as a parameter and not provide any defined #constants because it's obvious that EnableControl(true) means enable it
    and EnableControl(false) means disable it. After all, the other way round
    would be silly. They can't make the leap to the poor person totally unfamiliar
    with the API who sees EnableControl(false) embedded in a long and confusing
    function which is somehow setting the control to the wrong state.

    OTOH if you have #define CONTROL_ENABLE 42 few people will pass a raw 42.
     
    Malcolm McLean, Mar 2, 2014
    #18
  19. Jorgen Grahn

    Jorgen Grahn Guest

    I'll do that too. Except if stdbool.h (which I've never used) turned
    out to be universally loathed I might not bother.

    I was aware that it would be tricky to tell, since on comp.lang.c you
    can find people who feel strongly against /anything/.
    Fortunately for me 'const' is already accepted here. Otherwise we're
    conservative on average. C++ is foreign and threatening, and the C99
    features that /are/ used already leaked in via third-party libraries.

    These libraries don't use stdbool for some reason. Designated
    initializers and inline yes; stdbool and declarations not at the top
    of a block no. Perhaps they use the Linux kernel subset of C99.

    /Jorgen
     
    Jorgen Grahn, Mar 2, 2014
    #19
  20. Jorgen Grahn

    Eric Sosman Guest

    "No functionality" overstates (understates?) the reality;
    the _Bool type does in fact provide function not available via
    other types:

    int i = 0.1;
    if (i) puts("i is true");
    _Bool b = 0.1;
    if (b) puts("b is true");

    If you'd said "no *important* functionality," though, I'd have agreed.
     
    Eric Sosman, Mar 2, 2014
    #20
    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.