Different BOOL definitions problem

[Sergei Gnezdov]

I am using two different libraries. One defines BOOL as

typedef char BOOL; (neo_misc.h)

and another uses:

typedef unsigned char BOOL; (objc.h)

How do I solve the problem? How do you solve problems like this
without namespaces?

 

[Eric Sosman]

I am using two different libraries. One defines BOOL as

typedef char BOOL; (neo_misc.h)

and another uses:

typedef unsigned char BOOL; (objc.h)

How do I solve the problem? How do you solve problems like this
without namespaces?

It's clumsy, at best. Two possible approaches:

- Write your program so that each translation unit uses
one library or the other (or neither), but never both.
This may require that you write "wrappers" for the
libraries' functions.

- Use the preprocessor to change the names, e.g.
#define BOOL NEO_BOOL
#include "neo_misc.h"
#undef BOOL
#define BOOL OBJ_BOOL
#include "objc.h"
#undef BOOL
This can be made to work for the particular case you
describe, but will not work if the two headers define
conflicting macro names.

The first of these two approaches is "cleaner," but neither
is perfect. For example, if the two libraries use clashing
names with external linkage, there's no hope:

/* neo */
double trouble(void);

/* objc */
extern struct failure_s *trouble;

If this occurs, there's no portable way to use the two libraries
in the same C program -- you need to change the names, and if
you cannot change the libraries' sources this can only be done
(if it can be done) with system-specific non-portable magic.

 

[Richard Bos]

I am using two different libraries. One defines BOOL as

typedef char BOOL; (neo_misc.h)

and another uses:

typedef unsigned char BOOL; (objc.h)

How do I solve the problem? How do you solve problems like this
without namespaces?

You probably don't. One solution, since you're not going to pass a BOOL
with the value 243 or -17, might be to #include one header, #undef BOOL,
#include the other, and let the C automatic type conversions take care
of the difference between one BOOL and the other (and note that
converting from signed char to unsigned char is always possible, and the
result of converting 1 and 0, which is what TRUE and FALSE are probably
defined as, is predictable); but I can't guarantee that this is
completely correct, without knowing the content of the headers (or, for
that matter, libraries).
In this case, of course, a cop-out solution _could_ be to force your
implementation to make plain char unsigned, if both the implementation
and the first library make this possible.

Richard

 

[Keith Thompson]

You probably don't. One solution, since you're not going to pass a BOOL
with the value 243 or -17, might be to #include one header, #undef BOOL,
#include the other, and let the C automatic type conversions take care
of the difference between one BOOL and the other

[...]

BOOL is a typedef (or rather two typedefs), not a macro; #undef won't
work.