Re: Problem with Objective-C++ Header Files

On Fri, Jan 8, 2010 at 1:18 PM, Christopher Stern <[email protected]>wrote:

>
> On Jan 8, 2010, at 10:23 AM, Stephen Furlani wrote:
>
> Hello,
>
> I have attempted searching the archives, but the search function keeps
> truncating "objective-c++" to "objective-c  " so if there's a good location
> to look for this information, I can't find it.
>
> I have an extensive library of C++ code that I want to be able to
> incorporate into my Objective-C project.  Following the tutorials provided
> by Apple and others, I've renamed my object file to .mm to utilize
> Objective-C++.
>
> If I include the header files from my C++ library, I get a swath of errors,
> namely surrounding the use of 'id' in the subsequent included C++ header
> files.  I also get some more serious errors in the incompatibility between
> X.h (from XFree86) and objc.h over the use of 'BOOL' and 'cursors'.
>
>
> Renaming the object file back to .cpp, the project compiles without error,
> so I know it's because of the inclusion of the Objective-C keywords.
>
> How can I tell XCode to include those headers strictly as C++ headers and
> not Objective-C headers?  I thought using #include instead of #import would
> be clear enough.
>
>
> It doesn't work that way.
> The C/C++/ObjC #include/#import mechanism builds a new text file by dumping
> in the text of
> each included file at the point where the include occurs. Use XCode's
> build->preprocess command
> to see the text that's actually being sent to the compiler.
>
> You can do things like:
>
> #define cursors xcursors
> #include <X.h>
> #undef cursors
> #include <AppKit/AppKit .h>
>
> to work around conflicts like this.
>
> Note that it may be possible for much of your code to stay pure C++,
> and just have some GUI glue that needs to communicate with both Cocoa
> controls
> and your lib be .mm
>
> Understand also that XWindows is not the MacOSX's native display system,
> honestly X.h seems worst case scenario for this.
>

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() {}*

?

When I was working in VS, when you imported a C++ library into VB the import
needed to be exactly the same as what the lib was C extern'ing.

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

-- 
-Stephen Furlani
Biomedical Software Engineer
e: [email protected]
c: 240-491-7288