Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > rationale for #define true 1 in stdbool.h

Reply
Thread Tools

rationale for #define true 1 in stdbool.h

 
 
Ben Hinkle
Guest
Posts: n/a
 
      01-10-2006
I'm curious, what was the rationale for making a builtin type _Bool but then
having
#define true 1
#define false 0
in stdbool.h? That seems very odd that true and false don't have type _Bool.
In particular I'm poking around with some language extensions to C and one
of the most obvious extensions is overloading. Since "true" doesn't have
type _Bool it makes overloading behavior with _Bool very odd. You'd think
that at least it could be
#define true ((bool)1)

I notice in the C99 spec it says the true and false defines "are suitable
for use in #if preprocessor directives". Was it anticipated that true and
false would be used primarily for #if directives? One would imagine that a
more important property would be something like sizeof(bool) ==
sizeof(true).

thanks,
-Ben


 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      01-10-2006


Ben Hinkle wrote On 01/10/06 16:18,:
> I'm curious, what was the rationale for making a builtin type _Bool but then
> having
> #define true 1
> #define false 0
> in stdbool.h? That seems very odd that true and false don't have type _Bool.
> In particular I'm poking around with some language extensions to C and one
> of the most obvious extensions is overloading. Since "true" doesn't have
> type _Bool it makes overloading behavior with _Bool very odd. You'd think
> that at least it could be
> #define true ((bool)1)
>
> I notice in the C99 spec it says the true and false defines "are suitable
> for use in #if preprocessor directives". Was it anticipated that true and
> false would be used primarily for #if directives? One would imagine that a
> more important property would be something like sizeof(bool) ==
> sizeof(true).


"Suitable for use in #if" is one reason (bool)1 wouldn't
work. Types do not yet exist when the preprocessor operates,
so casts can't be evaluated. (In fact, #if true would turn
into #if (bool)1 and then #if (0)1, eliciting a diagnostic.)

As for the sizeof complaint, although opinions obviously
vary it doesn't strike me as an "important" property. IMHO
it is usually -- not always, but usually -- a poor idea to
write sizeof(type) when sizeof *ptr is practical. Besides,
we've already got sizeof 'x' > sizeof(char) on most systems,
and the only people it seems to bother are defectors to the
Dark Side With The Plus Signs.

Personally, I still don't understand the motivation for
adding _Bool to the language. The Rationale draws attention
to some properties of _Bool, but sheds no light on why those
properties were so desirable as to prompt the addition of a
whole new type -- especially since everything that can be
done with _Bool seems eminently do-able without it. Perhaps
the C9X committee suffered from Pascal envy?

--
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
 
 
 
Old Wolf
Guest
Posts: n/a
 
      01-11-2006
Eric Sosman wrote:

> Personally, I still don't understand the motivation for
> adding _Bool to the language.


For me, it's desirable because assigning any non-zero value
to it causes it to have a non-zero value. This is not true for
any builtin type except for unsigned long long, which would
be a waste of memory if it were used as a boolean type.

I have accidentally written code like this:

bool b = (flags & FLAG_FOO);

where FLAG_FOO is something like 0x100. It took a
long debugging session to track down the problem; even
when I'd isolated the problem to this one block of code,
I still couldn't for the life of me figure out what was going on,
until I looked up the definition of 'bool'. (It turned out to
be a typedef for unsigned char).

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-11-2006
"Ben Hinkle" <(E-Mail Removed)> writes:
> I'm curious, what was the rationale for making a builtin type _Bool but then
> having
> #define true 1
> #define false 0
> in stdbool.h? That seems very odd that true and false don't have type _Bool.
> In particular I'm poking around with some language extensions to C and one
> of the most obvious extensions is overloading. Since "true" doesn't have
> type _Bool it makes overloading behavior with _Bool very odd. You'd think
> that at least it could be
> #define true ((bool)1)
>
> I notice in the C99 spec it says the true and false defines "are suitable
> for use in #if preprocessor directives". Was it anticipated that true and
> false would be used primarily for #if directives? One would imagine that a
> more important property would be something like sizeof(bool) ==
> sizeof(true).


Character constants don't have type char either; they're of type int
(sizeof('a')==sizeof(int)).

Making true and false be of type _Bool wouldn't be very useful, since
they'd be promoted to int in most contexts anyway.

If the language had been changed so that all conditions must be of
type _Bool, rather than of any scalar type, making false and true be
of type _Bool might have made more sense -- but that kind of change
would break existing code.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Ben Hinkle
Guest
Posts: n/a
 
      01-11-2006

"Eric Sosman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
>
> Ben Hinkle wrote On 01/10/06 16:18,:
>> I'm curious, what was the rationale for making a builtin type _Bool but
>> then
>> having
>> #define true 1
>> #define false 0
>> in stdbool.h? That seems very odd that true and false don't have type
>> _Bool.
>> In particular I'm poking around with some language extensions to C and
>> one
>> of the most obvious extensions is overloading. Since "true" doesn't have
>> type _Bool it makes overloading behavior with _Bool very odd. You'd think
>> that at least it could be
>> #define true ((bool)1)
>>
>> I notice in the C99 spec it says the true and false defines "are suitable
>> for use in #if preprocessor directives". Was it anticipated that true and
>> false would be used primarily for #if directives? One would imagine that
>> a
>> more important property would be something like sizeof(bool) ==
>> sizeof(true).

>
> "Suitable for use in #if" is one reason (bool)1 wouldn't
> work. Types do not yet exist when the preprocessor operates,
> so casts can't be evaluated. (In fact, #if true would turn
> into #if (bool)1 and then #if (0)1, eliciting a diagnostic.)


Right. I wouldn't consider using true and false in #if's important.

> As for the sizeof complaint, although opinions obviously
> vary it doesn't strike me as an "important" property. IMHO
> it is usually -- not always, but usually -- a poor idea to
> write sizeof(type) when sizeof *ptr is practical. Besides,
> we've already got sizeof 'x' > sizeof(char) on most systems,
> and the only people it seems to bother are defectors to the
> Dark Side With The Plus Signs.


I'm with Them, then. Justifying one "mistake" (#define true 1) with another
(type of 'a' isn't char) doesn't make me feel warm and fuzzy. I assume there
are good reasons for things, though.

> Personally, I still don't understand the motivation for
> adding _Bool to the language. The Rationale draws attention
> to some properties of _Bool, but sheds no light on why those
> properties were so desirable as to prompt the addition of a
> whole new type -- especially since everything that can be
> done with _Bool seems eminently do-able without it. Perhaps
> the C9X committee suffered from Pascal envy?


Not enough Pascal envy, perhaps

>
> --
> (E-Mail Removed)
>



 
Reply With Quote
 
Peter Nilsson
Guest
Posts: n/a
 
      01-11-2006
Eric Sosman wrote:
>
> Personally, I still don't understand the motivation for
> adding _Bool to the language. The Rationale draws attention
> to some properties of _Bool, but sheds no light on why those
> properties were so desirable as to prompt the addition of a
> whole new type -- especially since everything that can be
> done with _Bool seems eminently do-able without it. Perhaps
> the C9X committee suffered from Pascal envy?


Or perhaps the C9X committee could see the plethora of
programs that already have varing (and subtly incompatible)
kludges for the same thing that was missing from C originally,
namely, a basic boolean type.

--
Peter

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-11-2006
Old Wolf wrote:

> Eric Sosman wrote:
>
>
>> Personally, I still don't understand the motivation for
>>adding _Bool to the language.

>
>
> For me, it's desirable because assigning any non-zero value
> to it causes it to have a non-zero value. This is not true for
> any builtin type except for unsigned long long, which would
> be a waste of memory if it were used as a boolean type.
>
> I have accidentally written code like this:
>
> bool b = (flags & FLAG_FOO);
>
> where FLAG_FOO is something like 0x100. It took a
> long debugging session to track down the problem; even
> when I'd isolated the problem to this one block of code,
> I still couldn't for the life of me figure out what was going on,
> until I looked up the definition of 'bool'. (It turned out to
> be a typedef for unsigned char).


Accidents will happen (and have to me, most certainly).
This particular accident isn't one that has beset my path
and laid a trap for my unwary feet; in the "isolate the
bit" context I tend to think of (and write) the result in
the same type as the original flags, not as a truth value
saying "was it set, or was it not?"

Still, if one wants the WISOWIN semantics, one can
always resort to the double negative:

bool b = !!(flags & FLAG_FOO);

or the (possibly clearer)

bool b = (flags & FLAG_FOO) != 0;

Thirty-five-plus years of C somehow scraped by without
anything more, and I still don't see what _Bool brings to
the party. Well, maybe I'm just a party pooper.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      01-11-2006
>Eric Sosman wrote:
>> Personally, I still don't understand the motivation for
>> adding _Bool to the language. ...


In article <(E-Mail Removed). com>
Peter Nilsson <(E-Mail Removed)> wrote:
>Or perhaps the C9X committee could see the plethora of
>programs that already have varing (and subtly incompatible)
>kludges for the same thing that was missing from C originally,
>namely, a basic boolean type.


In other words, there was a demand, so they filled it.

Of course, there is also a lot of demand for methamphetamine.

(Or as Rob Pike said of the X Window System: "Sometimes when you
fill a vacuum, it still sucks.")
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
Chuck F.
Guest
Posts: n/a
 
      01-11-2006
Eric Sosman wrote:
>

.... snip ...
>
> Thirty-five-plus years of C somehow scraped by without anything
> more, and I still don't see what _Bool brings to the party.
> Well, maybe I'm just a party pooper.


You can always avoid it by simply failing to #include <stdbool.h>.
Then the only evidence remaining is an identifier in the
implementors namespace. But for people who do want to define true,
false, and bool, everything is standardized.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
 
Reply With Quote
 
Alex Fraser
Guest
Posts: n/a
 
      01-11-2006
"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
[snip]
> Making true and false be of type _Bool wouldn't be very useful, since
> they'd be promoted to int in most contexts anyway.


Which leads to the obvious question: why are "small" types promoted to int?

> If the language had been changed so that all conditions must be of
> type _Bool, rather than of any scalar type, making false and true be
> of type _Bool might have made more sense -- but that kind of change
> would break existing code.


I guess you would also want to change the type of the result of the equality
and relational operators.

Alex


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[False,True] and [True,True] --> [True, True]????? bdb112 Python 45 04-29-2009 02:35 AM
Question about rationale for java.nio.Buffer design. Harald Kirsch Java 0 06-14-2004 12:15 PM
Re: The Sigma-Foveon pixel rationale Dave Martindale Digital Photography 2 04-02-2004 08:49 PM
Re: The Sigma-Foveon pixel rationale Dave Martindale Digital Photography 2 04-01-2004 05:01 PM
Re: The Sigma-Foveon pixel rationale David J. Littleboy Digital Photography 2 04-01-2004 08:11 AM



Advertisments