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

  1. Jorgen Grahn

    Kaz Kylheku Guest

    Note that this adds up as an argument against having reserved keywords.

    Because _Bool is a keyword, its use as an identifier in any scope,
    at any level of syntax is pervasively disallowed.

    Since bool is a preprocessor alias for _Bool, it then appears as if bool is
    also a keyword, even though preprocessor symbols lack lexical scoping.

    You are prohibited from uses of bool that would also be prohibited if
    bool were an actual keyword.
    If not being able to use "bool" or "false" as a local variable name
    or struct member is a problem, then so is not being able to use "int" or
    "extern" as a local variable name.

    (That argument can be made. I'm not making it here, but my point is that the
    argument should be properly generalized and shouldn't focus entirely on
    A typedef (or type specifier keyword) bool would be visible in debuggers as
    "bool", and values of objects of that type would show up as "true" and "false".

    (Of course, debuggers can support some hack whereby they provide an
    altered presentation of _Bool and its domain values.)
    Kaz Kylheku, Mar 30, 2014
    1. Advertisements

  2. Jorgen Grahn

    Ian Collins Guest

    The response from David Brown elsewhere in this thread says everything I
    was going to say here.
    Ian Collins, Mar 30, 2014
    1. Advertisements

  3. Jorgen Grahn

    Kaz Kylheku Guest

    There are other possible designs. For instance, it can easily be a run-time
    switchable decision in a compiler what it considers to be a reserved keyword.
    Pre-C99 code that defines its own true, false and bool in a way that is not
    compatible with C++ is not reasonable code. Reasonable code can have its
    bool, true and false retargetted to use the standard bool easily, probably
    just by the removal of those local definitions.

    Anyway, there is experience in the C programming community of
    porting C to C++, where you run into lots of keyword clashes.
    These problems are surmountable. One approach that is sometimes
    workable is to #define C++ keywords out of the way.

    The same could be done in a C90 program whose local bool is threatened by a new

    In other words, C programmers can implement their own dumb preprocessor
    renaming hacks as they see fit; such hacks don't have to be in the language.

    Dumb preprocessor renaming hacks which exist only in a code base can be
    eventually eliminated, or simply die of obsolescence along with their
    surrounding code base, leaving the language unscathed. Ones which are pushed
    into the language will tend to have a long and annoying lifespan.

    Also, a C program for which bool, true and false keywords are some
    kind of a big problem should perhaps just be compiled as C90 and not C99.

    Not all code that is C(X) needs to be automatically C(X+n) without
    any maintenance! Programs are still being compiled today as C90,
    or local dialects based on C90, 15 years after C99. Even newly-written
    programs that didn't exist in 1999.
    Kaz Kylheku, Mar 30, 2014
  4. Jorgen Grahn

    Tim Rentsch Guest

    Thank you! Coming from you, I'll take that as a compliment.
    Tim Rentsch, Mar 30, 2014
  5. Jorgen Grahn

    David Brown Guest

    I think the C committee's definition of "bool" was aimed as getting as
    close to a new keyword (or three new keywords) as they could, while
    avoiding the backwards compatibility issues of actually making "bool" a
    keyword. There had to be a new keyword somewhere, because bool cannot
    be fully defined in terms of an existing type (conversions to bool
    always end as 0 or 1), and there is no problem making _Bool a keyword as
    such names are already reserved.
    Fair enough. And for comparison, we could also look at the <stdint.h>
    types which are defined as typedefs rather than macros.

    My point is that code that used such standard type names as local
    variables or struct members, even where legal, would not be "perfectly
    reasonable". It is /legal/ to write code with declarations such as
    "int32_t uint16_t;" - since these types are declared as typedefs - but
    it is not reasonable code.
    This is indeed one of the possible advantages of a typedef enum bool.
    I doubt if many people have trouble with a debugger showing 1 and 0 for
    their bools instead of true and false, but true and false is arguably nicer.
    David Brown, Mar 31, 2014
  6. Jorgen Grahn

    David Brown Guest

    It certainly could be done that way, but the <stdbool.h> way makes it
    easier for people with pre-C99 code that does not fit with C99 bool to
    make use of other C99 features. Compiler switches would likely mean an
    all-or-nothing solution (i.e., enable C99 or not), or get very messy
    (such as dozens of switches to control different features from different
    standards). Plus, I think the C standards make a point of avoiding
    things like compiler options.
    I agree with you here, but different people have different opinions of
    what is "reasonable" and where to draw the line. For example, pre-C99
    code might define "bool" as "int" (via a typedef or macro) and rely on
    it being the same size as an "int". This could be called "reasonable" -
    after all, the return type of "==", "<", etc., are all "int". But I
    believe that most people would consider calling a local variable or
    struct member "true" to be "unreasonable".
    There are still plenty of modern C compilers that don't support C99, and
    plenty of coding standards that insist on pre-C99 styles. This is
    particularly true for embedded tools for small or specialised
    processors, and for coding standards for large projects where
    consistency is important.
    David Brown, Mar 31, 2014
  7. Jorgen Grahn

    Tim Rentsch Guest

    That is a stylistic opinion, not a fact. Defining these names as
    macros unnecessarily imposes a stylistic judgment on clients of
    that interface. Even if my own reaction in any particular
    instance were the same as yours (and I'm not sure it would be),
    as a general rule it's a bad idea for a language tool to impose
    stylistic judgments more than it has to. You may disagree with
    that, but if you think you're entitled to your own opinions then
    you should be willing to concede other people are entitled to
    their own opinions also.
    The problem is you didn't take the trouble to understand what was
    being claimed before reacting. I have now made several attempts
    in an effort to bring this aspect back into focus, unfortunately
    to no avail.
    Tim Rentsch, Apr 18, 2014
  8. Jorgen Grahn

    Tim Rentsch Guest

    That is not what I claimed. I'm sorry you don't understand that.
    I note that no one has bothered to answer any of the clarifying
    questions I have asked. There were two posed to you in the post
    you're responding to, and you didn't respond to either.
    I haven't accused anyone of anything. The problem we're having
    here, repeatedly, is that you keep hearing what you think I'm
    saying rather than what I am actually saying. If you want the
    discussion to be more productive, I suggest you put more effort
    into listening and understanding, and less into arguing.
    Tim Rentsch, Apr 18, 2014
  9. Jorgen Grahn

    David Brown Guest


    If you want to have a discussion, please reply in a timely fashion. If
    you don't get a chance to reply, that's fine - sometimes that happens,
    and not everyone has a chance to read and post daily. But you can't
    resurrect a long lead thread with a comment every few weeks and expect
    others to remember what they were thinking of at the time.

    As far as I am concerned, you made a claim that was a bit unreasonable,
    you failed to back it up with examples or evidence, and then bowed out
    of the discussion. That's fine, and long forgotten, with no harm done
    to your reputation here (as far as I am concerned, at least - I can't
    speak for others). But please don't keep dragging it up.
    David Brown, Apr 19, 2014
  10. Jorgen Grahn

    Tim Rentsch Guest

    I post to comp.lang.c not to have conversations but for the
    benefit of anyone who might want to read my comments. If you
    think you aren't getting any benefit from reading my postings,
    please feel free not to read them - I won't be offended.
    Tim Rentsch, Jun 12, 2014
  11. Jorgen Grahn

    David Brown Guest

    Fair enough, I suppose. I just think everyone - including yourself -
    would get more benefit when you reply while a thread is still active. I
    don't always agree with you, but I have learned things from some of your
    posts (perhaps especially when we have disagreed) - but it is hard when
    you write posts after such a delay that they are no longer in context.
    I have enough trouble remembering what I ate for breakfast this morning
    - I can't remember what we discussed three months ago!
    David Brown, Jun 12, 2014
    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.