Suggestions

Tony van der Hoff OSLib at mk-net.demon.co.uk
Fri Apr 28 09:52:38 BST 2000


On Thu, 27 Apr 2000, at 10:39:47, Jonathan Coxhead
<jonathan at doves.demon.co.uk> wrote on the subject "Suggestions":

>
> | 2. In types.h: 
> | 
> | typedef int osbool;
> | 
> | #if !defined( __GNUG__ ) && !defined( BOOL_DEFINED ) 
> |   typedef osbool bool;
> | #endif
>
>   There are 2 "natural laws" we should attempt to respect:
>
>      ---if |__cplusplus| is defined, |bool| is a keyword, and we
>      shouldn't touch it or rely on it anywhere.

That is not correct. As I pointed out in an earlier post, the other
mainstream C++ compiler for RISC OS, CFront, defines __cplusplus, but
does *not* define bool. 

Unfortunately, there doesn't seem to be any way of detecting CFront
specifically to allow an exception to be made.

>
>      ---in C99, |bool| is defined in <stdbool.h>, and we should
>      allow library users to use that, or not, as they see fit. In
>      practical terms, this means we shouldn't touch it or rely on it
>      anywhere in this case as well. There are no C99 compilers for
>      RISC O S (or anything) else yet, so we can make this change
>      safely.
>
How do we recognise C99? Does the standard define a compile-time flag?
Or will <stdbool.h> define a macro? 

Has anyone got a URL for the standard, please?

>   In other cases, we should do what we do now, to be compatible.
>
I agree.

>
> | Any future limitation on the use of a 4-byte bool can be taken 
>care of
> | by by the user defining BOOL_DEFINED, and using osbool.
>
>   I don't see what problem |BOOL_DEFINED| is solving. Is this for 
>non-C++, non-C99 systems that define |bool| themselves? Are there any?
>
Any case that we have not yet thought of. That includes cases where the
user for whatever reason wants to define his own version of bool, or is
using another library which itself defines bool. I bet there's someone
out there who thinks it'd be cool to write his own <stdbool.h>. I
wouldn't want to proscribe it.

I feel quite strongly that we should not encourage users to tinker with
the headers themselves in these cases, so giving them a catch-all switch
is the cleanest solution.


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



More information about the oslib-user mailing list