Re: Problem with Objective-C++ Header Files

Use combinations of

#if defined(__OBJC__)

and

#if defined(__cplusplus)

The first will be set for pure Objective-C (.m files), the second for pure C++ (.cp or .cpp) and both will be set for Objective-C++

Only include "id" when __OBJC__ is set

Shantonu Sen
[email protected]

Sent from my Mac Pro

On Jan 8, 2010, at 11:18 AM, Stephen Furlani wrote:

> 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
> _______________________________________________
> MacOSX-dev mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/macosx-dev