Re: Problem with Objective-C++ Header Files

On Jan 8, 2010, at 1:18 PM, Stephen Furlani wrote:

> 
> 
> On Fri, Jan 8, 2010 at 1:18 PM, Christopher Stern <[email protected]> wrote:
> 
> Thanks for the reply.  
> 
> The C++ library uses glxew, and the code claims to support AGL - http://www.equalizergraphics.com/, so I'm not intentionally using XWindows.  I suspect that XWindows is not being properly excluded for compiling on a Mac.  I'll have to dig deep for that.
> 
> I'm still a bit uncertain about using #define (and I'm wearing my C++ ignorance here on my sleeve) to re-define something in a header file that isn't redefined in the library.  If I do this:
> 
> #define id eqID
> #include "eq/eq.h"
> #undef id
> 
> and eq.h has 
> 
> class somethingA {
> private:
> void id ();
> }
> 
> #define'd to:
> 
> class somethingA {
> private:
> void eqID ();
> }
> 
> then it doesn't mess up eq.dylib which has
> 
> void somethingA::id() {}
> 
> and not
> 
> void somethingA::eqID() {}

You are correct that this could confuse the linker.

> There's also no way I can get XCode to just ignore Obj-C keywords in "eq/eq.h"?

No, the source file, with all '#include's '#include'ed is one stream of text to the compiler.
The good news is that I don't think there are any true ObjC keywords that don't start with '@'. 
There are some things defined in standard headers like BOOL that may be coming into conflict 
but that's a problem that exists in pure 'C' space the Obj-ness or ++-ness doesn't come into it.

Note 'id' in ObjC is a typedef, not a keyword:
typedef struct objc_object {
    Class isa;
} *id;
the example you give above, with a struct or class having a member called 'id' shouldn't produce any conflict
shouldn't need any defines or anything, in fact, there are standard MacOSX headers that have this.