stdbool.h

[Kaz Kylheku]

You are trying to tell us that the advantage of making bool, false and
true a typedef enum rather than macros is that you can re-use the names
as local variables and struct members?

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.

But re-using "bool", "false" or "true" as local variable names or struct
members is in no way "perfectly reasonable local use" - such code would
be cryptic and confusing, and would be highly unlikely to occur in even
the most badly written code.

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

So we are back to your original claim - either give us an example of
/perfectly reasonable/ use where macro bool would not work while typedef
bool would be valid, or accept that the macro versions work fine.

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

 

[Ian Collins]

Let me ask you the question I tried to ask Jacob Navia. Is
your question a generic question independent of the
identifiers involved, or are you asking specifically
regarding the identifiers 'bool', 'true', and 'false'?

The response from David Brown elsewhere in this thread says everything I
was going to say here.

 

[Kaz Kylheku]

On 10/03/14 20:35, Tim Rentsch wrote:

I can't imagine any "perfectly reasonable local uses" of bool,
true or false that conflict with this, nor can I imagine any
cryptic error messages as a result. If you can provide examples,
maybe I'll change my mind.

I think you have missed the point of what I've been saying. In
any case I cannot be responsible for your lack of imagination.

You /are/ responsible in this case for telling us that there are
"perfectly reasonable" cases where the <stdbool.h> macros would
cause conflicts but your typedef enum version would work, and
for telling us that there are cases where the enum version is
significantly better than the <stdbool.h> version. [snip
elaboration]

The problem is, I don't see any evidence that you've put in any
significant effort to understand what I've been saying, let alone
explore the consequences of the different alternatives. What
programs did you try compiling to see what sort of diagnostics
might be produced after doing a #include <stdbool.h>? Despite
what you may think, I am not responsible for doing the thinking
for people too lazy to think for themselves.

Most people - including myself - are fairly happy with macro bool. We
might have done it a little differently, but we accept it as a perfectly
workable solution, and we assume the C committee have done their job of
looking at the options and picking the one that gave a working system
with the least risk of breaking existing code.

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.

/You/ claim that macro bool breaks perfectly reasonable code, and gives
cryptic error messages.

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

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.

 

[Tim Rentsch]

And you're a totally arrogant arsehole. And to stand out as such
here is quite an achievement.

Thank you! Coming from you, I'll take that as a compliment.

 

[David Brown]

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.

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.

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

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.

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

This is indeed one of the possible advantages of a typedef enum bool.

(Of course, debuggers can support some hack whereby they provide an
altered presentation of _Bool and its domain values.)

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]

On 10/03/14 20:35, Tim Rentsch wrote:

I can't imagine any "perfectly reasonable local uses" of bool,
true or false that conflict with this, nor can I imagine any
cryptic error messages as a result. If you can provide examples,
maybe I'll change my mind.

I think you have missed the point of what I've been saying. In
any case I cannot be responsible for your lack of imagination.

You /are/ responsible in this case for telling us that there are
"perfectly reasonable" cases where the <stdbool.h> macros would
cause conflicts but your typedef enum version would work, and
for telling us that there are cases where the enum version is
significantly better than the <stdbool.h> version. [snip
elaboration]

The problem is, I don't see any evidence that you've put in any
significant effort to understand what I've been saying, let alone
explore the consequences of the different alternatives. What
programs did you try compiling to see what sort of diagnostics
might be produced after doing a #include <stdbool.h>? Despite
what you may think, I am not responsible for doing the thinking
for people too lazy to think for themselves.

Most people - including myself - are fairly happy with macro bool. We
might have done it a little differently, but we accept it as a perfectly
workable solution, and we assume the C committee have done their job of
looking at the options and picking the one that gave a working system
with the least risk of breaking existing code.

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.

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.

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.

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

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

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.

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.

 

[Tim Rentsch]

You are trying to tell us that the advantage of making bool, false
and true a typedef enum rather than macros is that you can re-use
the names as local variables and struct members? It is certainly
true that there are occasions when re-using a typedef name makes
sense (such as when writing "typedef struct S { ... } S;").

But re-using "bool", "false" or "true" as local variable names or
struct members is in no way "perfectly reasonable local use" -
such code would be cryptic and confusing, and would be highly
unlikely to occur in even the most badly written code.

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.

So we are back to your original claim - either give us an example
of /perfectly reasonable/ use where macro bool would not work
while typedef bool would be valid, or accept that the macro
versions work fine. (Note that I personally think typedef bool
would have been more elegant, but we are concerned here about what
works and what breaks.)

Secondly, give us an example of "rather cryptic error messages (or
worse?) in cases where these names are used in ways not in keeping
with the #define'd values" caused by the use of macro bool and
fixed by the use of typedef bool.

You made these claims, and were called on them - clearly and
repeatedly, by several people. If it turns out that you can't
find good examples, then say so - that's okay. It's fine to say
"macro bool is less elegant", or that it goes against good coding
practices - after all, typedef and enum were introduced as a
better solution than preprocessor macros for type definitions.
But you've made claims here, and you've brought up and old thread
to keep the issue alive - now it is time to show us "perfectly
reasonable" code or accept that while there is /legal/ code that
works with typedef bool and not with macro bool, such code is not
reasonable or realistic.

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]

On 10/03/14 20:35, Tim Rentsch wrote:

I can't imagine any "perfectly reasonable local uses" of bool,
true or false that conflict with this, nor can I imagine any
cryptic error messages as a result. If you can provide
examples, maybe I'll change my mind.

I think you have missed the point of what I've been saying. In
any case I cannot be responsible for your lack of imagination.

You /are/ responsible in this case for telling us that there are
"perfectly reasonable" cases where the <stdbool.h> macros would
cause conflicts but your typedef enum version would work, and
for telling us that there are cases where the enum version is
significantly better than the <stdbool.h> version. [snip
elaboration]

The problem is, I don't see any evidence that you've put in any
significant effort to understand what I've been saying, let alone
explore the consequences of the different alternatives. What
programs did you try compiling to see what sort of diagnostics
might be produced after doing a #include <stdbool.h>? Despite
what you may think, I am not responsible for doing the thinking
for people too lazy to think for themselves.

Most people - including myself - are fairly happy with macro bool.
We might have done it a little differently, but we accept it as a
perfectly workable solution, and we assume the C committee have
done their job of looking at the options and picking the one that
gave a working system with the least risk of breaking existing
code.

/You/ claim that macro bool breaks perfectly reasonable code, and
gives cryptic error messages.

That is not what I claimed. I'm sorry you don't understand that.

Every time I or someone else asks you to back up these claims with
examples, you procrastinate - you say you don't understand the
question, or that we others must find examples ourselves. Sorry,
but that is not how discussions or arguments work. /You/ made the
claim, /you/ provide the examples or the justification.

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.

We can all think of pros and cons for using macros, typedefs,
enums, language extensions, and mixtures between them. But no one
can read your mind as to the specific problems you have thought of
that macro bool has but typedef bool solves.

So either show us that you have a /real/ point, or stop accusing
people of being lazy or unimaginative because they won't do your
job for you.

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.

 

[David Brown]

David Brown <[email protected]> writes:

<snip>

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.

 

[Tim Rentsch]

<snip>

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.

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.

 

[David Brown]

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.

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!