[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

boolean usage

dr.oktopus

5/14/2011 9:06:00 PM

Hi,
I am developing a little library and I would like to develop it so
that it will be conforming both to the old and the new (c99) standard.
I have a function returning a boolean value, so I think that something
like:

file.h:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
#define bool int
#endif

/* rest of the header */

bool my_func (void);

file.c:

#if __STDC_VERSION__ >= 199901L
#define false 0
#define true (!false)
#endif

should be. But bool could be defined even in user code.
What's the proper way to handle this kind of things?
52 Answers

Keith Thompson

5/14/2011 11:41:00 PM

0

"dr.oktopus" <blindwilly@freeonline.zzn.com> writes:
> I am developing a little library and I would like to develop it so
> that it will be conforming both to the old and the new (c99) standard.
> I have a function returning a boolean value, so I think that something
> like:
>
> file.h:
>
> #if __STDC_VERSION__ >= 199901L
> #include <stdbool.h>
> #else
> #define bool int
> #endif
>
> /* rest of the header */
>
> bool my_func (void);
>
> file.c:
>
> #if __STDC_VERSION__ >= 199901L
> #define false 0
> #define true (!false)
> #endif
>
> should be. But bool could be defined even in user code.
> What's the proper way to handle this kind of things?

Well, code that doesn't use _Bool or <stdbool.h> can still conform to
both C90 and C99 (the C committee carefully designed it that way). But
if you want to use <stdbool.h> if it's available, perhaps with the goal
of dropping pre-C99 support eventually, there are several ways to do it.

The first thing I recommend reading is section 9 of the comp.lang.c FAQ,
<http://c-fa....

I'd probably use typedef rather than #define for the bool type, but
that's a fairly minor point.

I'm not sure why you define "bool" in file.h and "true" and "false" in
file.c. And there's no point in defining true as (!false); 1 and 0 are
clear enough.

Here's how I might do it:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#endif

The enum isn't *exactly* equivalent to C99's _Bool/bool, but it's not
hard to restrict your usage to cases where it's close enough.

On the other hand, as you say, the names "bool", "false", and "true"
might be defined in some other header and your own names could conflict
with them. In that case, you can pick a unique prefix and do something
like:

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#define FOO_bool bool
#define FOO_false false
#define FOO_true true
#else
typedef enum { FOO_false, FOO_true } FOO_bool;
#endif

That's quite ugly; you'll have to decide whether it's worth it.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Ben Bacarisse

5/15/2011 3:19:00 AM

0

Keith Thompson <kst-u@mib.org> writes:

> "dr.oktopus" <blindwilly@freeonline.zzn.com> writes:
>> I am developing a little library and I would like to develop it so
>> that it will be conforming both to the old and the new (c99) standard.
>> I have a function returning a boolean value, so I think that something
>> like:
>>
>> file.h:
>>
>> #if __STDC_VERSION__ >= 199901L
>> #include <stdbool.h>
>> #else
>> #define bool int
>> #endif
<snip>
> I'd probably use typedef rather than #define for the bool type, but
> that's a fairly minor point.

I think a typedef is neater (in some vague aesthetic way) but a macro
has the advantage that a program that uses the library and also defines
its own bool can suppress it's own definition if need be. You might
even be lucky and not have to do anything if the definitions are the
same. That option won't be available with a typedef in the library's
header file.

<snip>
--
Ben.

dr.oktopus

5/15/2011 6:13:00 AM

0

errata corrige

>
> file.c:
>
> #if __STDC_VERSION__ < 199901L
> #define false 0
> #define true (!false)
> #endif
>

Malcolm McLean

5/15/2011 6:39:00 AM

0

On May 15, 12:05 am, "dr.oktopus" <blindwi...@freeonline.zzn.com>
wrote:
> But bool could be defined even in user code.
> What's the proper way to handle this kind of things?
>
Bool breaks libraries. Just return an int, to be on the safe side.

Datesfat Chicks

5/15/2011 2:58:00 PM

0

On Sat, 14 May 2011 14:05:43 -0700 (PDT), "dr.oktopus"
<blindwilly@freeonline.zzn.com> wrote:

>Hi,
>I am developing a little library and I would like to develop it so
>that it will be conforming both to the old and the new (c99) standard.
>I have a function returning a boolean value, so I think that something
>like:
>
>file.h:
>
>#if __STDC_VERSION__ >= 199901L
>#include <stdbool.h>
>#else
>#define bool int
>#endif
>
>/* rest of the header */
>
>bool my_func (void);
>
>file.c:
>
>#if __STDC_VERSION__ >= 199901L
>#define false 0
>#define true (!false)
>#endif
>
>should be. But bool could be defined even in user code.
>What's the proper way to handle this kind of things?

I do embedded work with small micros (2K of RAM is a high-end part for
me), so every bit has to count.

I typically use _Bool_ or _Boolean_ (forget what the right keyword
is). Anyway, that does a few neat things in the development tools:

a)It causes the linker to manage RAM at the bit level (rather than the
byte level). So you can link a bunch of modules together each with
_Bool_'s, and variables from different modules are actually often in
the same byte. No RAM wasted! The tools pack the bits.

b)The little microcontrollers typically have instructions to set,
clear, and test bits of RAM economically, so it is pretty efficient.
It is rare to find a micro where something like this is requied:

ld a, whatever
or a, #64
ld whatever, a

Most little micros can do that in one instruction--a RMW sequence such
as I demonstrated above is rare.

All that being said ...

I really don't see a compelling need for Boolean variables in most
programs written for larger machines, except in the cases where there
are arrays of them and it would be a huge RAM waste (and then you'd
want to have an array of integers and mask bits in and out).

In most cases with larger machines, an "int" is just fine as a
Boolean. Wasting 31 or 63 bits is a non-issue.

The only thing I'd caution you to do is that if you're going to agree
that a variable is Boolean, it has two equivalence classes:

a)0 = FALSE

b)Everything else is TRUE.

So, don't do this in the code:

if (variable == TRUE)

If you do that, then there are a large number of values that are
neither TRUE nor FALSE.

Use "(variable)" and "(!variable)" instead.

And of course use || and &&.

I just don't see a need for _Bool_ in most large programs.

"int" is just fine.

DFC

Malcolm McLean

5/15/2011 3:13:00 PM

0

On May 15, 5:58 pm, Datesfat Chicks <datesfat.chi...@gmail.com> wrote:
>
> I just don't see a need for _Bool_ in most large programs.
>
> "int" is just fine.
>
It documents what the variable is.

void circle(int x, int y, int r, bool fill)

is obvious how to use, int fill might be passing an option from a menu
of fill patterns.

Keith Thompson

5/16/2011 3:10:00 PM

0

Datesfat Chicks <datesfat.chicks@gmail.com> writes:
[...]
> I do embedded work with small micros (2K of RAM is a high-end part for
> me), so every bit has to count.
>
> I typically use _Bool_ or _Boolean_ (forget what the right keyword
> is). Anyway, that does a few neat things in the development tools:
>
> a)It causes the linker to manage RAM at the bit level (rather than the
> byte level). So you can link a bunch of modules together each with
> _Bool_'s, and variables from different modules are actually often in
> the same byte. No RAM wasted! The tools pack the bits.
[...]

Either your tools are generating C code that emulates 1-bit objects
using either bit fields or bitwise operations, or your C compiler
is non-conforming. In standard C, if you apply sizeof to an object,
type, or expression of any type, the result is at least 1 byte,
which is at least 8 bits. (sizeof can't be applied to bit fields.)

This is just an observation; I don't suggest that there's anything
wrong with a non-conforming implementation. But I don't think your
situation is an argument for or against using _Bool in standard C.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Datesfat Chicks

5/16/2011 11:45:00 PM

0

On Mon, 16 May 2011 08:09:39 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Datesfat Chicks <datesfat.chicks@gmail.com> writes:
>[...]
>> I do embedded work with small micros (2K of RAM is a high-end part for
>> me), so every bit has to count.
>>
>> I typically use _Bool_ or _Boolean_ (forget what the right keyword
>> is). Anyway, that does a few neat things in the development tools:
>>
>> a)It causes the linker to manage RAM at the bit level (rather than the
>> byte level). So you can link a bunch of modules together each with
>> _Bool_'s, and variables from different modules are actually often in
>> the same byte. No RAM wasted! The tools pack the bits.
>[...]
>
>Either your tools are generating C code that emulates 1-bit objects
>using either bit fields or bitwise operations, or your C compiler
>is non-conforming. In standard C, if you apply sizeof to an object,
>type, or expression of any type, the result is at least 1 byte,
>which is at least 8 bits. (sizeof can't be applied to bit fields.)

Interesting discussion. I wasn't aware it was non-comforming.

I consider it a gift from The Heavens. Every one of those variables
saves 7 bits of RAM!

>This is just an observation; I don't suggest that there's anything
>wrong with a non-conforming implementation. But I don't think your
>situation is an argument for or against using _Bool in standard C.

DFC

Keith Thompson

5/17/2011 12:47:00 AM

0

Datesfat Chicks <datesfat.chicks@gmail.com> writes:
> On Mon, 16 May 2011 08:09:39 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
[...]
>>Either your tools are generating C code that emulates 1-bit objects
>>using either bit fields or bitwise operations, or your C compiler
>>is non-conforming. In standard C, if you apply sizeof to an object,
>>type, or expression of any type, the result is at least 1 byte,
>>which is at least 8 bits. (sizeof can't be applied to bit fields.)
>
> Interesting discussion. I wasn't aware it was non-comforming.
>
> I consider it a gift from The Heavens. Every one of those variables
> saves 7 bits of RAM!
[...]

In some environments, the 7 bits of RAM saved for each Boolean
stored in 1 bit rather than 8 would be more than wiped out by the
increase in the size of the code needed to access it.

The tradeoff could well be different in your environment, either if
no extra machine code is needed to access single bits (depends on
the CPU, or if space for variables is in much shorter supply than
code space (ROM?).

For large arrays of booleans, of course, it's a different story.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Peter Nilsson

5/17/2011 1:23:00 AM

0

"dr.oktopus" <blindwi...@freeonline.zzn.com> wrote:
> Hi,
> I am developing a little library and I would like to develop
> it so that it will be conforming both to the old and the new
> (c99) standard. I have a function returning a boolean value,
> so I think that something like:
>
> file.h:
>
> #if __STDC_VERSION__ >= 199901L
> #include <stdbool.h>
> #else
> #define bool int

I prefer...

typedef unsigned bool;

....since _Bool is an unsigned integer type and should work
as expected in a bitfield of width 1.

--
Peter