Question

I have a lot of code in C++, originally built on a PC. I’m trying to make it work with Objective-C on a Mac. To that end, I created an Objective-C framework to house the C++ code and added a thin wrapper. But I’m running into a typedef problem in my C++ code.

When I was working with C++ on a PC I used the BOOL variable defined in WinDef.h. So when I moved everything over the Mac I added in typedef int BOOL; to make sure the BOOL variable would still compile as expected.

But when I try to compile I get an error: “Conflicting declaration 'typedef int BOOL'“. I assume this is because BOOL is a keyword in Objective-C, and so is already defined. I also can’t just use the Objective-C BOOL since it is an unsigned char and not an int.

While I was looking for possible solutions I found one that mentions undefining BOOL, but I couldn’t find how to do that (nor do I know if it actually works). Another suggests renaming BOOL in the C++ files to something that isn’t a keyword. This suggestion isn’t an option for me because other projects rely on the C++ code. Ideally, any changes I make should stay in one file or at least should not negatively impact the code on a Windows machine.

How can I undefine the Objective-C definition of BOOL for my C++ files and use the C++ definition I added? Is there a better way to deal with this problem?

In case it helps I’m using: Xcode 3.2.5, 64-bit and Mac OS X 10.6.6

Thanks for any guidance!

Answer 1

I’m a little confused by some of the discussion, but instead of typedef int BOOL; how about just:

#ifndef BOOL
  #define BOOL int
#endif

If you’re using typedef then #undef won’t work since they are two different things. #define/#undef operate on preprocessor symbols that perform replacements, whereas a typedef is part of the language that creates an alias of another type.

A preprocessor symbol can be undefined at any point because it is simply an instruction to the preprocessor that tells it to no longer use that definition when performing replacements. However, a typedef can’t be undefined, as it is something that gets created within a particular scope, rather than the linear processing that occurs using the preprocessor. (In the same way, you wouldn’t expect to be able to declare a global variable int x; and then at some point in your code be able to say ‘stop recognizing x as a variable.’)

The reason I suggest the #define in my answer is that it’s possible that the ObjectiveC #define is being hit only while compiling some of your code. That could be an explanation as to why you may get errors in your C++ when you removed the typedef, but still get a conflict if it is in. But, so, if the assumptions are correct, once you check for the definition prior to trying to define it, you should be able to avoid the conflicting definitions when they occur.

As a final note: in this particular situation, you could also just put your typedef inside the check instead of a #define. However, I gravitated toward doing it the way I did both because it’s a very common idiom, and because that block will also prevent you from defining it twice in your C++ code if it ends up included twice. Probably neither very compelling reasons if you very much prefer the typedef and know it’s not an issue in the code. 🙂