Suggestions

[Tony van der Hoff]

On Mon, 24 Apr 2000, at 23:14:41, Jonathan Coxhead
<jonathan at doves.demon.co.uk> wrote on the subject "Suggestions":

> | 
> | The only way to avoid troubles is to use something 'unique' as
> | 'osbool' with corresponding 'ostrue' and 'osfalse'.
>
>   Ick! 
>
I'm obviously missing something fundamental; what is so bad about that?

>   The other way to avoid trouble is to avoid compilers that have the 
>problem. Obviously, M$ isn't a problem for us. If Norcroft C99 
>(if/when it appears) and GNU C/C++ both have |sizeof (bool) == 4| 
>then we have no issue.
>
>   If they have some other setting, we still have no issue with C---
>just don't include <stdbool.h> in C99, but do what we do now.
>
OK, it's all a bit academic, but what happens to people who compile some
units of their application using types.h, and other units using
stdbool.h? Or, even worse, want to link to another library which has its
own ideas about bool (quite legitimately, using stdbool.h)?

>   But C++ would be a problem ... |bool, true, false| are keywords. I 
>suppose in that case, we'd have to blow the backwards compatibility, 
>and use |osbool, ostrue, osfalse|. Either that, or see if we can use 
>the native type (by adding it to the "ByteWide" type list, and having 
>separate libraries for C and C++). "Ick!" again, but that might be 
>best.
>
To me, that seems ickier than the original suggestion. 

We can easily typedef bool from osbool, etc for use in the interface to
take care of backwards compatibility where bool is not provided
elsewhere; we can cast osbool to bool where the compiler provides the
latter and the sizes are the same; or we can use raw osbool where the
sizes don't match. It would be nice to provide an implicit type
conversion for C++, but I'm not sure about how to do this.

This situation is no worse than the present one and has the advantage
that we would have the flexibility of addressing each issue as it
arises, without the need for a library re-build. The knowledgeable user
could even do it in his own code if necessary.

> | Or still
> | sticking to the current situation and hoping the standard commitee
> | will never assign a new meaning to 'TRUE' & 'FALSE'...
>
>   This is my preference.

Well, it avoids hassle :-)
-- 
Tony van der Hoff         |  Mailto:tony at mk-net.demon.co.uk
                          |  Mailto:avanderhoff at iee.org
Buckinghamshire, England  |  http:www.mk-net.demon.co.uk