pll: who uses _Bool

Szabolcs Nagy wrote:

who has used _Bool? (or included stdbool.h for bool, true, false?)

(i'm considering using it in a library for home projects)

Since <stdbool.hisn't available on all the relevant compilers, I stil
roll my own boolean definitions. I should perhaps switch to lower-case
now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

My C page: http://www.pg2.moo.no/C/index.html
-include Win32 build of splint 3.1.2

Oct 28 '07 #3

Ark Khasin

Szabolcs Nagy wrote:

who has used _Bool? (or included stdbool.h for bool, true, false?)

(i'm considering using it in a library for home projects)

IMHO, bool (or _Bool) goes hand in hand with static inline (and an
optimizing compiler). Otherwise, you will immediately pay performance
and code size penalties for syntactic sugar, and if you don't have to
care, C might not be the right language for your project.
I mean, types aside, semantic Booleans are not free:
int cmpneq(int a, int b) {return a!=b;}
is less efficient than
int cmpneq(int a, int b) {return a-b;}

--
Ark

Oct 28 '07 #4

Tor Rustad <to********@hotmail.comwrites:

Szabolcs Nagy wrote:
>who has used _Bool? (or included stdbool.h for bool, true, false?)
(i'm considering using it in a library for home projects)

Since <stdbool.hisn't available on all the relevant compilers, I
stil roll my own boolean definitions. I should perhaps switch to
lower-case now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

__STDC_IEC_559__ tells you whether the implementation conforms to the
IEC 60559 floating-point standard.

What you probably want is

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

But note that an implementation might provide <stdbool.hwithout
fully conforming to C99 or having __STDC_VERSION__ >= 199901L. An
alternative is to use mechanisms outside the language to test during
configuration whether <stdbool.hexists. (But occasionally using the
enum when <stdbool.his available isn't a big problem.)

You also have to be a bit careful with the code that uses ``bool'';
the enum type doesn't fully capture the semantics of C99's _Bool.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 28 '07 #5

Ark Khasin <ak*****@macroexpressions.comwrites:

Szabolcs Nagy wrote:
>who has used _Bool? (or included stdbool.h for bool, true, false?)
(i'm considering using it in a library for home projects)

IMHO, bool (or _Bool) goes hand in hand with static inline (and an
optimizing compiler). Otherwise, you will immediately pay performance
and code size penalties for syntactic sugar, and if you don't have to
care, C might not be the right language for your project.
I mean, types aside, semantic Booleans are not free:
int cmpneq(int a, int b) {return a!=b;}
is less efficient than
int cmpneq(int a, int b) {return a-b;}

The first has the considerable advantage of being correct. The
``a-b'' version exhibits undefined behavior on overflow. Consider
``cmpneq(INT_MIN, INT_MAX)''.

And how do you know that ``a!=b'' is less efficient than ``a-b''?
Have you measured it? Depending on the architecture, it's possible
that each could compile to a single instruction.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 28 '07 #6

Ben Pfaff

Tor Rustad <to********@hotmail.comwrites:

Since <stdbool.hisn't available on all the relevant compilers, I
stil roll my own boolean definitions. I should perhaps switch to
lower-case now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

For what it's worth, the standard says that true, false, and bool
are macros, not enumerations or typedef names. (Not that this
will often make a difference in practice.)
--
"If I've told you once, I've told you LLONG_MAX times not to
exaggerate."
--Jack Klein

Oct 28 '07 #7

Tor Rustad wrote:

Szabolcs Nagy wrote:

>who has used _Bool? (or included stdbool.h for bool, true, false?)
(i'm considering using it in a library for home projects)

Since <stdbool.hisn't available on all the relevant compilers, I
stil roll my own boolean definitions. I should perhaps switch to
lower-case now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

I suggest that whenever you do so, you duplicate exactly the
statements (or a subset of them) that you find in stdbool.h. Read
the c standard to discover what they are. Of course _Bool will not
exist. That way you won't run into trouble when the system is
compiled under C99 up.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Oct 28 '07 #8

Ark Khasin

Keith Thompson wrote:

Ark Khasin <ak*****@macroexpressions.comwrites:
>Szabolcs Nagy wrote:
>>who has used _Bool? (or included stdbool.h for bool, true, false?)
(i'm considering using it in a library for home projects)

IMHO, bool (or _Bool) goes hand in hand with static inline (and an
optimizing compiler). Otherwise, you will immediately pay performance
and code size penalties for syntactic sugar, and if you don't have to
care, C might not be the right language for your project.
I mean, types aside, semantic Booleans are not free:
int cmpneq(int a, int b) {return a!=b;}
is less efficient than
int cmpneq(int a, int b) {return a-b;}

The first has the considerable advantage of being correct. The
``a-b'' version exhibits undefined behavior on overflow. Consider
``cmpneq(INT_MIN, INT_MAX)''.

Sorry. I ought to be more careful. Here is a repaired version:
int cmpneq(int a, int b) {return a^b;}
As a practical matter though, I've always seen a-b+b yielding a and thus
a-b didn't evaluate to 0. I know it's a meek defense in this ng. :)

>
And how do you know that ``a!=b'' is less efficient than ``a-b''?
Have you measured it? Depending on the architecture, it's possible
that each could compile to a single instruction.

I may have limited exposure, but I've never seen an instruction set that
would invent a 1 or 0 out of non-equal or equal a and b in a single
instruction. Every instruction set I've seen can invent a non-0 or a 0
out of non-equal or equal a and b in a single instruction [common
disclaimers on sizeof(int) vs. register size apply].
It's likely that a Boolean version can _never_ be more efficient than
the integer one, and in most cases is less efficient.

--
Ark

Oct 28 '07 #9

Chris Torek

In article <kbWUi.601$mv.257@trndny08>
Ark Khasin <ak*****@macroexpressions.comwrote:

>I may have limited exposure, but I've never seen an instruction set that
would invent a 1 or 0 out of non-equal or equal a and b in a single
instruction.

MIPS architecture:

setne t0,a,b /* assuming a and b are in registers */

(In fact, if you want to *test* whether a != b, you have to use a
setne instruction to set a register to 1 or 0, followed by a branch
on register value instruction. I am not sure whether t0 is a
conventional target register for this; the "t", "v", and "a"
registers are the most likely candidates though.)

>Every instruction set I've seen can invent a non-0 or a 0
out of non-equal or equal a and b in a single instruction [common
disclaimers on sizeof(int) vs. register size apply].

Yes, most can do this with subtract or exclusive-or (or both),
including MIPS. However, care must be used with subtract, lest
one get an integer-overflow exception (on MIPS this means using
the "unsigned" instructions, on x86 it means using xor or making
sure you never set the trap bit, on SPARC it means not adding a
"trap on condition codes" instruction, etc.).

>It's likely that a Boolean version can _never_ be more efficient than
the integer one, and in most cases is less efficient.

This is why compilers optimize. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.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.

Oct 28 '07 #10

Ark Khasin wrote:

It's likely that a Boolean version can _never_ be more efficient than
the integer one, and in most cases is less efficient.

In the cases where any difference in efficiency would be noticed, the
function is probably trivial enough to be inlined away.

--
Ian Collins.

Oct 28 '07 #11

Malcolm McLean

"Tor Rustad" <to********@hotmail.comwrote in message

Szabolcs Nagy wrote:
>who has used _Bool? (or included stdbool.h for bool, true, false?)

(i'm considering using it in a library for home projects)

Since <stdbool.hisn't available on all the relevant compilers, I stil
roll my own boolean definitions. I should perhaps switch to lower-case
now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

This is the same mistake as

#define start {

but a little bit more subtle.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Oct 28 '07 #12

cr88192

"Szabolcs Nagy" <ns*******@gmail.comwrote in message
news:11**********************@o38g2000hse.googlegr oups.com...

who has used _Bool? (or included stdbool.h for bool, true, false?)

(i'm considering using it in a library for home projects)

personally, I don't see any real advantage of _Bool, apart from the vague
possibility of it serving as a programmer hint...
and, it is ugly...
so, C99:
some features are useful (complex and long long, for example);
some features just add complexity (dynamic arrays, ...);
some features are, IMO, frivolous...

and, worse in the case of bool: it is not present...
the version of mingw I am using lacks stdbool.h...
and, what is more, so does cygwin...

so, if one can convince themselves that it is useful, they then have to find
a compiler that has it...

or something...
now, that is not to stop some people from being like:
#ifndef bool
#define bool int
#endif
#ifndef true
#define true 1
#endif
#ifndef false
#define false 0
#endif

where I have seen similar in at least a few projects...

Oct 28 '07 #13

Ben Bacarisse

Ark Khasin <ak*****@macroexpressions.comwrites:

Keith Thompson wrote:
>Ark Khasin <ak*****@macroexpressions.comwrites:
>>Szabolcs Nagy wrote:
who has used _Bool? (or included stdbool.h for bool, true, false?)
(i'm considering using it in a library for home projects)

IMHO, bool (or _Bool) goes hand in hand with static inline (and an
optimizing compiler). Otherwise, you will immediately pay performance
and code size penalties for syntactic sugar, and if you don't have to
care, C might not be the right language for your project.
I mean, types aside, semantic Booleans are not free:
int cmpneq(int a, int b) {return a!=b;}
is less efficient than
int cmpneq(int a, int b) {return a-b;}

The first has the considerable advantage of being correct. The
``a-b'' version exhibits undefined behavior on overflow. Consider
``cmpneq(INT_MIN, INT_MAX)''.
Sorry. I ought to be more careful. Here is a repaired version:
int cmpneq(int a, int b) {return a^b;}

There are, I think, some corner cases that make this non-portable.
Even on two's compliment implementations, ^ can result in a trap
representation. My non-authoritative PDF has some change bars here
(6.2.6.2) so this may be a recent clarification.

--
Ben.

Oct 28 '07 #14

Army1987

On Sat, 27 Oct 2007 22:19:35 -0700, Ben Pfaff wrote:

Tor Rustad <to********@hotmail.comwrites:
>Since <stdbool.hisn't available on all the relevant compilers, I
stil roll my own boolean definitions. I should perhaps switch to
lower-case now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

For what it's worth, the standard says that true, false, and bool
are macros, not enumerations or typedef names. (Not that this
will often make a difference in practice.)

Well, #if true will do the wrong thing... But I can't think of
any other difference. But using macros, the most reasonable choice
for bool in C89 is int, whereas with an enum an implementation is
allowed to choose a smaller type if it thinks it is equally (or
more) efficient, in particular I'd expect sizeof (_Bool) to equal
sizeof (enum {false, true}) on most of implementations having
_Bool.

--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

Oct 28 '07 #15

Eric Sosman

Ben Pfaff wrote:

Tor Rustad <to********@hotmail.comwrites:
>Since <stdbool.hisn't available on all the relevant compilers, I
stil roll my own boolean definitions. I should perhaps switch to
lower-case now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

For what it's worth, the standard says that true, false, and bool
are macros, not enumerations or typedef names. (Not that this
will often make a difference in practice.)

Notice that the definition above is not quite equivalent
to C99's bool. Here's a way to see the difference:

bool b;
b = 42;
if (b == 1)
puts ("C99-style bool");
else
puts ("Trickery is rampant");

That is, converting *any* non-zero value to C99 bool produces
the value `(bool)1'.

--
Eric Sosman
es*****@ieee-dot-org.invalid

Oct 28 '07 #16

"Eric Sosman" <es*****@ieee-dot-org.invalida écrit dans le message de
news: cq******************************@comcast.com...

Ben Pfaff wrote:
>Tor Rustad <to********@hotmail.comwrites:
>>Since <stdbool.hisn't available on all the relevant compilers, I
stil roll my own boolean definitions. I should perhaps switch to
lower-case now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

For what it's worth, the standard says that true, false, and bool
are macros, not enumerations or typedef names. (Not that this
will often make a difference in practice.)

Notice that the definition above is not quite equivalent
to C99's bool. Here's a way to see the difference:

bool b;
b = 42;
if (b == 1)
puts ("C99-style bool");
else
puts ("Trickery is rampant");

That is, converting *any* non-zero value to C99 bool produces
the value `(bool)1'.

Does it convert NaNs to true ?

--
Chqrlie.

Oct 28 '07 #17

Eric Sosman

Charlie Gordon wrote:

"Eric Sosman" <es*****@ieee-dot-org.invalida écrit dans le message de
news: cq******************************@comcast.com...
>Ben Pfaff wrote:
>>Tor Rustad <to********@hotmail.comwrites:
Since <stdbool.hisn't available on all the relevant compilers, I
stil roll my own boolean definitions. I should perhaps switch to
lower-case now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif
For what it's worth, the standard says that true, false, and bool
are macros, not enumerations or typedef names. (Not that this
will often make a difference in practice.)
Notice that the definition above is not quite equivalent
to C99's bool. Here's a way to see the difference:

bool b;
b = 42;
if (b == 1)
puts ("C99-style bool");
else
puts ("Trickery is rampant");

That is, converting *any* non-zero value to C99 bool produces
the value `(bool)1'.

Does it convert NaNs to true ?

Yes. 6.3.1.2:

"When any scalar value is converted to _Bool,
the result is 0 if the value compares equal
to 0; otherwise, the result is 1."

Since NaN does not compare equal to 0, the conversion yields 1.

--
Eric Sosman
es*****@ieee-dot-org.invalid

Oct 28 '07 #18

Ark Khasin <ak*****@macroexpressions.comwrites:

Keith Thompson wrote:
>Ark Khasin <ak*****@macroexpressions.comwrites:

[...]

>>I mean, types aside, semantic Booleans are not free:
int cmpneq(int a, int b) {return a!=b;}
is less efficient than
int cmpneq(int a, int b) {return a-b;}
The first has the considerable advantage of being correct. The
``a-b'' version exhibits undefined behavior on overflow. Consider
``cmpneq(INT_MIN, INT_MAX)''.
Sorry. I ought to be more careful. Here is a repaired version:
int cmpneq(int a, int b) {return a^b;}

[...]

Bitwise operations on signed types always make me nervous.

In this case, for an implementation that uses ones'-complement or
sign-and-magnitude, a^b will fail if a is +0 and b is -0.

The language has a built-in != operator. Just use it. Don't
micro-optimize unless it's absolutely necessary.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 28 '07 #19

"cr88192" <cr*****@nospam.hotmail.comwrites:
[...]

and, worse in the case of bool: it is not present...
the version of mingw I am using lacks stdbool.h...
and, what is more, so does cygwin...

[...]

Cygwin does provide <stdbool.h>. Perhaps you just need to update your
system.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 28 '07 #20

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

Ark Khasin <ak*****@macroexpressions.comwrites:
>Keith Thompson wrote:
>>Ark Khasin <ak*****@macroexpressions.comwrites:

[...]

>>>I mean, types aside, semantic Booleans are not free:
int cmpneq(int a, int b) {return a!=b;}
is less efficient than
int cmpneq(int a, int b) {return a-b;}
The first has the considerable advantage of being correct. The
``a-b'' version exhibits undefined behavior on overflow. Consider
``cmpneq(INT_MIN, INT_MAX)''.
Sorry. I ought to be more careful. Here is a repaired version:
int cmpneq(int a, int b) {return a^b;}
[...]

Bitwise operations on signed types always make me nervous.

In this case, for an implementation that uses ones'-complement or
sign-and-magnitude, a^b will fail if a is +0 and b is -0.

Close, but no cigar ;-)

On those obsolete museum pieces, in the case you describe, a^b would be -0,
a value that compares equal to 0, so the result is correct. But you are
just off by a little: if a=1 and b=-1, a^b yields -0 as well, which of
course is a problem.

The language has a built-in != operator. Just use it. Don't
micro-optimize unless it's absolutely necessary.

Absolutely!

--
Chqrlie.

Oct 28 '07 #21

Keith Thompson wrote:

Tor Rustad <to********@hotmail.comwrites:
>Szabolcs Nagy wrote:
>>who has used _Bool? (or included stdbool.h for bool, true, false?)
(i'm considering using it in a library for home projects)
Since <stdbool.hisn't available on all the relevant compilers, I
stil roll my own boolean definitions. I should perhaps switch to
lower-case now, using something ala:

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

__STDC_IEC_559__ tells you whether the implementation conforms to the
IEC 60559 floating-point standard.

Ooops. I had just finished porting the latest splint package, and was
posting at 4 AM, instead of going to bed.

What you probably want is

#if __STDC_VERSION__ >= 199901L

Yes

#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

But note that an implementation might provide <stdbool.hwithout
fully conforming to C99 or having __STDC_VERSION__ >= 199901L. An
alternative is to use mechanisms outside the language to test during
configuration whether <stdbool.hexists. (But occasionally using the
enum when <stdbool.his available isn't a big problem.)

One such relevant case, could be GNU GCC. However, I haven't even
started using "gcc -std=c99 ..." yet, and don't see any problems with
avoiding <stdbool.h>, as long as GCC is C99 non-conforming.

The main advantage of using lowercase bool/true/false, would really be
getting syntax coloring in editors. :)

You also have to be a bit careful with the code that uses ``bool'';
the enum type doesn't fully capture the semantics of C99's _Bool.

Well, I don't expect any problems in my existing code, which for
production quality, typically is lint clean.

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

My C page: http://www.pg2.moo.no/C/index.html
-include Win32 build of splint 3.1.2

Oct 28 '07 #22

CBFalconer wrote:

Tor Rustad wrote:

[..]

>#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

I suggest that whenever you do so, you duplicate exactly the
statements (or a subset of them) that you find in stdbool.h. Read
the c standard to discover what they are. Of course _Bool will not
exist. That way you won't run into trouble when the system is
compiled under C99 up.

Really? Why is using typeless macros under C89 bullet-proof???

Macros doesn't strike me as a good alternative for C89, shutting down
type checking... rarely is a good advice.

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

My C page: http://www.pg2.moo.no/C/index.html
-include Win32 build of splint 3.1.2

Oct 28 '07 #23

Army1987 wrote:

Well, #if true will do the wrong thing... But I can't think of
any other difference. But using macros, the most reasonable choice
for bool in C89 is int, whereas with an enum an implementation is
allowed to choose a smaller type if it thinks it is equally (or
more) efficient, in particular I'd expect sizeof (_Bool) to equal
sizeof (enum {false, true}) on most of implementations having
_Bool.

Why? I'd have thought the opposite would be true. Why would an
implementation use anything other than sizeof(int) for the size of an
enum (unless an implementation specific pragma were used)?

--
Ian Collins.

Oct 28 '07 #24

Ben Pfaff

Ian Collins <ia******@hotmail.comwrites:

Why would an implementation use anything other than sizeof(int)
for the size of an enum (unless an implementation specific
pragma were used)?

To save memory?
--
Ben Pfaff
http://benpfaff.org

Oct 28 '07 #25

"Tor Rustad" <to********@hotmail.coma écrit dans le message de news:
zv*********************@telenor.com...

CBFalconer wrote:
>Tor Rustad wrote:

[..]

>>#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

I suggest that whenever you do so, you duplicate exactly the
statements (or a subset of them) that you find in stdbool.h. Read
the c standard to discover what they are. Of course _Bool will not
exist. That way you won't run into trouble when the system is
compiled under C99 up.

Really? Why is using typeless macros under C89 bullet-proof???

Macros doesn't strike me as a good alternative for C89, shutting down type
checking... rarely is a good advice.

Use this:

#undef bool
typedef enum {false, true} bool;
#define false ((bool)+0)
#define true ((bool)+1)

Have the best of both worlds: the enum for type definition and debugging,
the macros for preprocessing, but that expand to a typed constant.

--
Chqrlie.

Oct 28 '07 #26

Ben Pfaff wrote:

Ian Collins <ia******@hotmail.comwrites:

>Why would an implementation use anything other than sizeof(int)
for the size of an enum (unless an implementation specific
pragma were used)?

To save memory?

OK, but I wouldn't expect it as a default. On the random samples of 32
and 64 bit machines I've tried, the following prints "1 4".

#include <stdbool.h>
#include <stdio.h>

typedef enum {efalse, etrue} ebool;

int main() {
printf( "%d %d\n", sizeof(bool), sizeof(ebool) );
}
I hit a problem with this last week, someone was integrating some C code
into a C++ test harness and wondered why they were seeing garbage values
when reading back members of a struct that had a bool member. The C
compiler saw the enum definition in the header and used 4 for
sizeof(bool), the C++ compiler just used built in bool with 1 as
sizeof(bool).

--
Ian Collins.

Oct 28 '07 #27

Flash Gordon

Ian Collins wrote, On 28/10/07 19:01:

Army1987 wrote:

>Well, #if true will do the wrong thing... But I can't think of
any other difference. But using macros, the most reasonable choice
for bool in C89 is int, whereas with an enum an implementation is
allowed to choose a smaller type if it thinks it is equally (or
more) efficient, in particular I'd expect sizeof (_Bool) to equal
sizeof (enum {false, true}) on most of implementations having
_Bool.

Why? I'd have thought the opposite would be true. Why would an
implementation use anything other than sizeof(int) for the size of an
enum (unless an implementation specific pragma were used)?

Something other than an int might be used because it was more efficient.
For example, on an 8 bit processor an 8 bit type is likely to be far
more efficient.
--
Flash Gordon

Oct 28 '07 #28

Flash Gordon wrote:

Ian Collins wrote, On 28/10/07 19:01:
>Army1987 wrote:

>>Well, #if true will do the wrong thing... But I can't think of
any other difference. But using macros, the most reasonable choice
for bool in C89 is int, whereas with an enum an implementation is
allowed to choose a smaller type if it thinks it is equally (or
more) efficient, in particular I'd expect sizeof (_Bool) to equal
sizeof (enum {false, true}) on most of implementations having
_Bool.

Why? I'd have thought the opposite would be true. Why would an
implementation use anything other than sizeof(int) for the size of an
enum (unless an implementation specific pragma were used)?

Something other than an int might be used because it was more efficient.
For example, on an 8 bit processor an 8 bit type is likely to be far
more efficient.

Maybe, *might* be used I agree with, I was questioning "in particular
I'd *expect* sizeof (_Bool) to equal sizeof (enum {false, true}) on most
of implementations having _Bool".

--
Ian Collins.

Oct 28 '07 #29

Tor Rustad wrote:

CBFalconer wrote:
Tor Rustad wrote:

[..]

>>#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif

I suggest that whenever you do so, you duplicate exactly the
statements (or a subset of them) that you find in stdbool.h. Read
the c standard to discover what they are. Of course _Bool will not
exist. That way you won't run into trouble when the system is
compiled under C99 up.

Really? Why is using typeless macros under C89 bullet-proof???

Macros doesn't strike me as a good alternative for C89, shutting
down type checking... rarely is a good advice.

Macros don't shut down type checking. They do text replacement,
and the resultant expression gets as type-checked as the compiler
is capable of.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Oct 28 '07 #30

CBFalconer wrote:

Tor Rustad wrote:
>CBFalconer wrote:
>>Tor Rustad wrote:
[..]

>>>#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif
I suggest that whenever you do so, you duplicate exactly the
statements (or a subset of them) that you find in stdbool.h. Read
the c standard to discover what they are. Of course _Bool will not
exist. That way you won't run into trouble when the system is
compiled under C99 up.
Really? Why is using typeless macros under C89 bullet-proof???

Macros doesn't strike me as a good alternative for C89, shutting
down type checking... rarely is a good advice.

Macros don't shut down type checking. They do text replacement,
and the resultant expression gets as type-checked as the compiler
is capable of.

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

?

Why this the above *better* under C89, than using

typedef enum {false, true} bool;

?

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

"To this day, many C programmers believe that 'strong typing' just means
pounding extra hard on the keyboard"

Oct 28 '07 #31

"Tor Rustad" <to********@hotmail.coma écrit dans le message de news:
oM*********************@telenor.com...

CBFalconer wrote:
>Tor Rustad wrote:
>>CBFalconer wrote:
Tor Rustad wrote:
[..]

#ifdef __STDC_IEC_559__
#include <stdbool.h>
#else
typedef enum {false, true} bool;
#endif
I suggest that whenever you do so, you duplicate exactly the
statements (or a subset of them) that you find in stdbool.h. Read
the c standard to discover what they are. Of course _Bool will not
exist. That way you won't run into trouble when the system is
compiled under C99 up.
Really? Why is using typeless macros under C89 bullet-proof???

Macros doesn't strike me as a good alternative for C89, shutting
down type checking... rarely is a good advice.

Macros don't shut down type checking. They do text replacement,
and the resultant expression gets as type-checked as the compiler
is capable of.

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

true and false will expand to int constants.

Why this the above *better* under C89, than using

typedef enum {false, true} bool;

consider this:

#if true
....
#endif

The standard explicitly allows this, and mandates that true be defined to 1
for that very purpose (7.16p3). with just the enum, #if true ultimately
evaluates to #if 0. QED

--
Chqrlie.

Oct 29 '07 #32

"Charlie Gordon" <ne**@chqrlie.orgwrites:

"Tor Rustad" <to********@hotmail.coma écrit dans le message de news:
oM*********************@telenor.com...

[...]

>Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

true and false will expand to int constants.

>Why this the above *better* under C89, than using

typedef enum {false, true} bool;

consider this:

#if true
...
#endif

The standard explicitly allows this, and mandates that true be defined to 1
for that very purpose (7.16p3). with just the enum, #if true ultimately
evaluates to #if 0. QED

It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.hin C90. You can write code that reproduces most
of the *useful* semantics, such as:

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

and then just use them normally, but avoid any trickery like expecting
conversions to bool to work as they do in C99.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 29 '07 #33

Tor Rustad wrote:

CBFalconer wrote:

.... snip ...

>>
Macros don't shut down type checking. They do text replacement,
and the resultant expression gets as type-checked as the compiler
is capable of.

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

The macro has nothing to do with type. Wherever the id 'true'
appears, it will be replaced by the id '1'. Similarly for 'false'
and '0'. Any type checking depends entirely on the use of those
ids (0 and 1) in the resultant expression.

For example, the expression sequence:

size_t st;
...
st = -true;

whill result in st setting to SIZE_T_MAX, whatever that may be.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Oct 29 '07 #34

CBFalconer <cb********@yahoo.comwrites:

Tor Rustad wrote:
>CBFalconer wrote:
... snip ...

>>>
Macros don't shut down type checking. They do text replacement,
and the resultant expression gets as type-checked as the compiler
is capable of.

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

The macro has nothing to do with type. Wherever the id 'true'
appears, it will be replaced by the id '1'. Similarly for 'false'
and '0'. Any type checking depends entirely on the use of those
ids (0 and 1) in the resultant expression.

``true'' and ``false'' are identifers (I presume that's what you mean
by "id"); ``0'' and ``1'' are not. Yes, I'm nitpicking, but correct
terminology is important.

For example, the expression sequence:

size_t st;
...
st = -true;

whill result in st setting to SIZE_T_MAX, whatever that may be.

Yes, but that's not relevant to the type of ``true''.

``true'' expands to the integer constant ``1'', which is of type int,
regardless of the context in which it appears. (In some contexts, it
may then be implicitly converted to some other type.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 29 '07 #35

Flash Gordon

Ian Collins wrote, On 28/10/07 20:07:

Flash Gordon wrote:
>Ian Collins wrote, On 28/10/07 19:01:
>>Army1987 wrote:

Well, #if true will do the wrong thing... But I can't think of
any other difference. But using macros, the most reasonable choice
for bool in C89 is int, whereas with an enum an implementation is
allowed to choose a smaller type if it thinks it is equally (or
more) efficient, in particular I'd expect sizeof (_Bool) to equal
sizeof (enum {false, true}) on most of implementations having
_Bool.

Why? I'd have thought the opposite would be true. Why would an
implementation use anything other than sizeof(int) for the size of an
enum (unless an implementation specific pragma were used)?
Something other than an int might be used because it was more efficient.
For example, on an 8 bit processor an 8 bit type is likely to be far
more efficient.

Maybe, *might* be used I agree with, I was questioning "in particular
I'd *expect* sizeof (_Bool) to equal sizeof (enum {false, true}) on most
of implementations having _Bool".

I would expect them to be the same size because if it is the most
efficient way to implement one it is the most efficient way to implement
the other. I can also see why they might be different.
--
Flash Gordon

Oct 29 '07 #36

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:
>Tor Rustad wrote:
>>CBFalconer wrote:

... snip ...
>>>>
Macros don't shut down type checking. They do text replacement,
and the resultant expression gets as type-checked as the compiler
is capable of.

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

The macro has nothing to do with type. Wherever the id 'true'
appears, it will be replaced by the id '1'. Similarly for 'false'
and '0'. Any type checking depends entirely on the use of those
ids (0 and 1) in the resultant expression.

``true'' and ``false'' are identifers (I presume that's what you
mean by "id"); ``0'' and ``1'' are not. Yes, I'm nitpicking, but
correct terminology is important.

>For example, the expression sequence:

size_t st;
...
st = -true;

whill result in st setting to SIZE_T_MAX, whatever that may be.

Yes, but that's not relevant to the type of ``true''.

``true'' expands to the integer constant ``1'', which is of type
int, regardless of the context in which it appears. (In some
contexts, it may then be implicitly converted to some other type.)

I disagree. I can affect the macro expansion with the '#'
operation. This can change the "1" resulting from the macro
expansion to, say, 1u. No change to the macro is required. The
primary thing that happens is the '1' appears in the code. I can
even envelop that alteration in further ridiculous macros.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Oct 29 '07 #37

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Tor Rustad wrote:
CBFalconer wrote:

... snip ...
>
Macros don't shut down type checking. They do text replacement,
and the resultant expression gets as type-checked as the compiler
is capable of.

Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

The macro has nothing to do with type. Wherever the id 'true'
appears, it will be replaced by the id '1'. Similarly for 'false'
and '0'. Any type checking depends entirely on the use of those
ids (0 and 1) in the resultant expression.

``true'' and ``false'' are identifers (I presume that's what you
mean by "id"); ``0'' and ``1'' are not. Yes, I'm nitpicking, but
correct terminology is important.

>>For example, the expression sequence:

size_t st;
...
st = -true;

whill result in st setting to SIZE_T_MAX, whatever that may be.

Yes, but that's not relevant to the type of ``true''.

``true'' expands to the integer constant ``1'', which is of type
int, regardless of the context in which it appears. (In some
contexts, it may then be implicitly converted to some other type.)

I disagree. I can affect the macro expansion with the '#'
operation. This can change the "1" resulting from the macro
expansion to, say, 1u. No change to the macro is required. The
primary thing that happens is the '1' appears in the code. I can
even envelop that alteration in further ridiculous macros.

The question was:

>>>Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

I fail to see how the hypothetical usage of the # operator is relevant
to the question. The types of true, false, and INT_MAX are all the
same: int.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 29 '07 #38

Keith Thompson wrote:

>

.... snip ...

>
The question was:

>>>>Now, what is the type of true and false, when using:
>
$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

I fail to see how the hypothetical usage of the # operator is
relevant to the question. The types of true, false, and INT_MAX
are all the same: int.

My point is that we don't have a typed identifier at all. We have
created another representation for the digit 1 (or for 0). Yes,
the unadorned use of such digits can generate an int type constant,
however we are not limited to such unadorned use.

The characters 'true' are simply another glyph for the digit '1'.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

Oct 30 '07 #39

"CBFalconer" <cb********@yahoo.coma écrit dans le message de news:
47***************@yahoo.com...

Keith Thompson wrote:
>>
... snip ...
>>
The question was:

>>>>>Now, what is the type of true and false, when using:
>>
>$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
>[...]
>#define true 1
>#define false 0

I fail to see how the hypothetical usage of the # operator is
relevant to the question. The types of true, false, and INT_MAX
are all the same: int.

My point is that we don't have a typed identifier at all. We have
created another representation for the digit 1 (or for 0). Yes,
the unadorned use of such digits can generate an int type constant,
however we are not limited to such unadorned use.

The characters 'true' are simply another glyph for the digit '1'.

Not for the digit 1, for the one-digit token ``1''
Anyway, your point is ridiculous: any identifier can be transmogrified into
something else with macro based token pasting.

int x;
long x1;

Q: what is the type of x?
A: int of course.
CBF: not if I do this: GLUE(x,1) with an appropriate definition of GLUE.

--
Chqrlie.

Oct 30 '07 #40

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

"Charlie Gordon" <ne**@chqrlie.orgwrites:
>"Tor Rustad" <to********@hotmail.coma écrit dans le message de news:
oM*********************@telenor.com...
[...]

>>Now, what is the type of true and false, when using:

$ cat /usr/lib/gcc/i486-linux-gnu/4.1.2/include/stdbool.h
[...]
#define true 1
#define false 0

true and false will expand to int constants.

>>Why this the above *better* under C89, than using

typedef enum {false, true} bool;

consider this:

#if true
...
#endif

The standard explicitly allows this, and mandates that true be defined to
1
for that very purpose (7.16p3). with just the enum, #if true ultimately
evaluates to #if 0. QED

It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.hin C90. You can write code that reproduces most
of the *useful* semantics, such as:

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

Safer this way:

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

--
Chqrlie.

Oct 30 '07 #41

"Charlie Gordon" <ne**@chqrlie.orgwrites:

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

[...]

>It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.hin C90. You can write code that reproduces most
of the *useful* semantics, such as:

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

Safer this way:

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

How is that significantly safer? My version is, IMHO, the most
straightforward way to define a Boolean type in C90. Adding the
macros for false and true (which hide the enumeration constants
without changing their type or value) would only matter in
preprocessor directives. It emulates one small aspect of C99, while
making the definition more complicated. Conversions to bool still
don't work in the C99 manner, so you still have to be just as careful
in how you use bool, false, and true.

I don't think the added #defines are worth the effort. Keep it
simple.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Oct 30 '07 #42

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...

"Charlie Gordon" <ne**@chqrlie.orgwrites:
>"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...
[...]

>>It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.hin C90. You can write code that reproduces most
of the *useful* semantics, such as:

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

Safer this way:

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

How is that significantly safer? My version is, IMHO, the most
straightforward way to define a Boolean type in C90. Adding the
macros for false and true (which hide the enumeration constants
without changing their type or value) would only matter in
preprocessor directives. It emulates one small aspect of C99, while
making the definition more complicated. Conversions to bool still
don't work in the C99 manner, so you still have to be just as careful
in how you use bool, false, and true.

I don't think the added #defines are worth the effort. Keep it
simple.

They are not much of an effort, and if the case should arise that true is
used in a preprocessor conditional, the bug could be quite difficult to nail
down.

--
Chqrlie.

Oct 30 '07 #43

Charlie Gordon wrote:

"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...
>"Charlie Gordon" <ne**@chqrlie.orgwrites:
>>"Keith Thompson" <ks***@mib.orga écrit dans le message de news:
ln************@nuthaus.mib.org...
[...]
>>>It's just not possible to completely reproduce the semantics of C99's
_Bool and <stdbool.hin C90. You can write code that reproduces most
of the *useful* semantics, such as:

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

#if __STDC_VERSION__ >= 199901L
#include <stdbool.h>
#else
typedef enum { false, true } bool;
#define false 0
#define true 1
#endif
How is that significantly safer? My version is, IMHO, the most
straightforward way to define a Boolean type in C90. Adding the
macros for false and true (which hide the enumeration constants
without changing their type or value) would only matter in
preprocessor directives. It emulates one small aspect of C99, while
making the definition more complicated. Conversions to bool still
don't work in the C99 manner, so you still have to be just as careful
in how you use bool, false, and true.

I don't think the added #defines are worth the effort. Keep it
simple.

They are not much of an effort, and if the case should arise that true is
used in a preprocessor conditional, the bug could be quite difficult to nail
down.

I'm siding with Keith here, adding those macros result in more
hard-to-read code, and don't help against a common bug, at least have I
never seen user defined booleans used as pp-token.

IMO, rather using a lint tool, would give a real effect.

--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>

Oct 30 '07 #44