gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa compatability header file


From: Kazunobu Kuriyama
Subject: Re: Cocoa compatability header file
Date: Thu, 22 Apr 2004 07:43:32 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1

Fred Kiefer wrote:

Kazunobu Kuriyama wrote:

Fred Kiefer wrote:

Kazunobu Kuriyama wrote:

The general idea looks ok. But are you sure the proposed header can live with C99 and (reportedly coming) ObjC++? I mean, the typedef and the following define's
seem to be problematic.


No, I am not sure. If you have any suggestions on how to make this header file safer against upcoming compiler changes these are very welcome.



Honestly, I know almost nothing about ObjC++. So I'm happy if someone who knows the
stuff well corrects mistakes possibly made in the code below.

Since bool has been a predefined type in C++ and C99 (AFAIK, as of GCC 3.1 for the
latter), I think the following makes the thing safer:

#ifndef GCC_VERSION
#if __GNUC__ > 3
#define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCH_LEVEL__)
#else
#define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100)
#endif

#if (!defined(__cplusplus)) || GCC_VERSION < 30100
typedef BOOL bool
#define false NO
#define true  YES
#endif

The strange thing is that I am using GCC 3.3.1 and these where not defined for me. What about checking __USE_ISOC99 instead? I really don't have much of a glue here, so this is just guessing.

You'll never get anything strange as long as the header stdbool.h is not included. If some source code uses the type bool, it is highly likely to include the header directly or indirectly (if it compiles). So I though some protection against it is
needed for any compatibility header like the proposed one.

Because the degree of C99 support varies depending on GCC's versions, I don't think
relying on __USE_ISOC99 is a good idea.

The directives above contain some mistakes:

(1) __GNU_PATCH_LEVEL__ should be
   __GNUC_PATCHLEVEL__
(2) (!defined(__cplusplus)) || GCC_VERSION < 30100 should be
   (!defined(__cplusplus)) && GCC_VERSION < 30100

Sorry for that.

(In my view, this sort of stuff should go into a header which is supposed to be included in almost all of the GNUstep headers, say GSConfig.h. Is this wrong?)


As I wrote, I don't want to see these names being used in normal GNUstep code. It is better to keep the definitions out ouf our normal headers, otherwise we would encourage people to use them.

That's right. But we should also note the fact that this sort of usage (eg. using the type bool, or stuff not included in ObjC) is rather likely to happen with the code the GNUstep users write. As that's beyond our control, it is desirable for us to take care of it. Yes, that's annoying. But we hardly expect those who use Cocoa.h to do finer control over compilation on their side, because Cocoa.h is just for such
guys (apart from the role you put on it for GNUstep).

Furthermore, it is necessary to consider the case where _Bool (in GCC, it's a typedef of bool.) is used in user's source code. As the porposed directives doesn't deal with
the case, some extra work must be done for that.

Anyway, my intention was to let you know about messy boolean stuff in C/ObjC/C++/ObjC++, not to try to fix the proposed header. I hope you'll find a better way to get around it
once you take a look at stdbool.h.

Regards,
- Kazunobu Kuriyama






reply via email to

[Prev in Thread] Current Thread [Next in Thread]