Velocity Reviews > pll: who uses _Bool

pll: who uses _Bool

Charlie Gordon
Guest
Posts: n/a

 10-28-2007
"Keith Thompson" <(E-Mail Removed)> a écrit dans le message de news:
http://www.velocityreviews.com/forums/(E-Mail Removed)...
> Ark Khasin <(E-Mail Removed)> writes:
>> Keith Thompson wrote:
>>> Ark Khasin <(E-Mail Removed)> writes:

> [...]
>>>> 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.

Guest
Posts: n/a

 10-28-2007
Keith Thompson wrote:
> Tor Rustad <(E-Mail Removed)> 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.

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

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 <(E-Mail Removed) | 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

Charlie Gordon
Guest
Posts: n/a

 10-28-2007
"Keith Thompson" <(E-Mail Removed)> a écrit dans le message de news:
(E-Mail Removed)...
> "cr88192" <(E-Mail Removed)> writes:
> [...]
>> 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.

When you do that, do not invoke cygwin's setup from bash: it breaks the
whole distribution, crashes setup, and even rebooting as documented does not
fix it. Cygwin setup keeps crashing. To fix the problem you need to edit
the file c:/cygwin/etc/setup/installed.db and remove the line that starts
with 'bash '.

This is OT, but I just wasted 30 minutes on this crap.

--
Chqrlie.

Guest
Posts: n/a

 10-28-2007
CBFalconer 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 <(E-Mail Removed) | 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

Ben Bacarisse
Guest
Posts: n/a

 10-28-2007
"Charlie Gordon" <(E-Mail Removed)> writes:

> "Keith Thompson" <(E-Mail Removed)> a Ã©crit dans le message de news:
> (E-Mail Removed)...
>> Ark Khasin <(E-Mail Removed)> writes:
>>> Keith Thompson wrote:
>>>> Ark Khasin <(E-Mail Removed)> writes:

>> [...]
>>>>> 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.

Not always. An implementation is allowed to "not support negative
zero" and, on these implementations, ^ operations that produce -0
constitute undefined behaviour. Even on two's compliment machines,
sign bit 1 and all value bits 0 is allowed to be a trap
representation.

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

>
> Absolutely!

I can only add another voice to the this call. Compare values with
operations that deal with values, not ones that deal in
representations.

--
Ben.

Ian Collins
Guest
Posts: n/a

 10-28-2007
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.

Ben Pfaff
Guest
Posts: n/a

 10-28-2007
Ian Collins <(E-Mail Removed)> writes:

> 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

Flash Gordon
Guest
Posts: n/a

 10-28-2007
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

Charlie Gordon
Guest
Posts: n/a

 10-28-2007
"Tor Rustad" <(E-Mail Removed)> a écrit dans le message de news:
(E-Mail Removed)...
> CBFalconer 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.

Charlie Gordon
Guest
Posts: n/a

 10-28-2007
"Ben Bacarisse" <(E-Mail Removed)> a écrit dans le message de news:
(E-Mail Removed)...
> "Charlie Gordon" <(E-Mail Removed)> writes:
>
>> "Keith Thompson" <(E-Mail Removed)> a écrit dans le message de news:
>> (E-Mail Removed)...
>>> Ark Khasin <(E-Mail Removed)> writes:
>>>> Keith Thompson wrote:
>>>>> Ark Khasin <(E-Mail Removed)> writes:
>>> [...]
>>>>>> 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.

>
> Not always. An implementation is allowed to "not support negative
> zero" and, on these implementations, ^ operations that produce -0
> constitute undefined behaviour. Even on two's compliment machines,
> sign bit 1 and all value bits 0 is allowed to be a trap
> representation.

Jinx! there is always one more bug

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

>>
>> Absolutely!

>
> I can only add another voice to the this call. Compare values with
> operations that deal with values, not ones that deal in
> representations.

And if you so concerned with efficiency, you can tell the compiler to
optimize with the !! operator:

int cmpneq(int a, int b) { return !!(a != b); }

Or in the VC world:

int cmpneq(int a, int b) { return ("opt:/O2/NODRMCHECK", a != b); }

--
Chqrlie