Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   pll: who uses _Bool (http://www.velocityreviews.com/forums/t547360-pll-who-uses-_bool.html)

Szabolcs Nagy 10-27-2007 03:41 PM

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

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


Malcolm McLean 10-27-2007 04:11 PM

Re: who uses _Bool
 

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

Here's what Dennis Ritchie has to say about it

"Of the new things, restricted pointers probably are a help; variadic macros
and bool are just adornment. I've heard the argument for complex numbers for
a long time, and maybe it was inevitable, but it does somewhat increase the
cross-product of the type rules and inflate the library. One issue the
question didn't mention is the introduction of the "long long" type and its
implications, which is one of the more contentious issues in discussion
groups about the language -- and it also makes the type-promotion rules much
more complicated. But of course, 64-bit machines and storage are here, and
it had to be faced."
http://www.itworld.com/Comp/3380/lw-12-ritchie/

use bool not _Bool, though. Bool breaks libraries.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm





Tor Rustad 10-28-2007 03:00 AM

Re: 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.h> isn'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 <bwzcab@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

Ark Khasin 10-28-2007 03:26 AM

Re: 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)
>

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

Keith Thompson 10-28-2007 04:38 AM

Re: pll: who uses _Bool
 
Tor Rustad <tor_rustad@hotmail.com> writes:
> 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.h> isn'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.h> without
fully conforming to C99 or having __STDC_VERSION__ >= 199901L. An
alternative is to use mechanisms outside the language to test during
configuration whether <stdbool.h> exists. (But occasionally using the
enum when <stdbool.h> is 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) kst-u@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"

Keith Thompson 10-28-2007 04:41 AM

Re: pll: who uses _Bool
 
Ark Khasin <akhasin@macroexpressions.com> writes:
> 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) kst-u@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"

Ben Pfaff 10-28-2007 05:19 AM

Re: pll: who uses _Bool
 
Tor Rustad <tor_rustad@hotmail.com> writes:
> Since <stdbool.h> isn'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

CBFalconer 10-28-2007 06:00 AM

Re: pll: who uses _Bool
 
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.h> isn'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


Ark Khasin 10-28-2007 06:42 AM

Re: pll: who uses _Bool
 
Keith Thompson wrote:
> Ark Khasin <akhasin@macroexpressions.com> writes:
>> 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

Chris Torek 10-28-2007 07:03 AM

Re: pll: who uses _Bool
 
In article <kbWUi.601$mv.257@trndny08>
Ark Khasin <akhasin@macroexpressions.com> wrote:
>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 (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.


All times are GMT. The time now is 08:23 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.