views:

554

answers:

3

I'm trying to mix C++ and Objective-C, I've made it most of the way but would like to have a single interface class between the Objective-C and C++ code. Therefore I would like to have a persistent C++ object in the ViewController interface.

This fails by forbidding the declaration of 'myCppFile' with no type:

#import <UIKit/UIKit.h>
#import "GLView.h"
#import "myCppFile.h"

@interface GLViewController : UIViewController <GLViewDelegate>
{
    myCppFile cppobject;
}

@end

However this works just fine in the .mm implementation file (It doesn't work because I want cppobject to persist between calls)

#import "myCppFile.h"
@implementation GLViewController
- (void)drawView:(UIView *)theView
{
    myCppFile cppobject;
    cppobject.draw();
}
A: 

I think you need to set the following flat to true in your project settings:

GCC_OBJC_CALL_CXX_CDTORS = YES

This should allow you to instantiate C++ objects in your ObjC classes.

Martin Cote
This didn't seem to work. I'm using Xcode 3.2.1 and the 3.0 iphone SDK.
Winder
+1  A: 

Make sure that all files that include GLViewController.h are Objective-C++ sources (*.mm).

When you include C++ code in the header of your view controller, all sources that import this header must be able to understand it, so they must be in Objective-C++

oefe
+9  A: 

You should use opaque pointers and only include C++ headers in the file that implements your Objective-C class. That way you don't force other files that include the header to use Objective-C++:

// header:
#import <UIKit/UIKit.h>
#import "GLView.h"

struct Opaque;

@interface GLViewController : UIViewController <GLViewDelegate>
{
    struct Opaque* opaque;
}
// ...
@end

// source file:
#import "myCppFile.h"

struct Opaque {
    myCppFile cppobject;
};

@implementation GLViewController
// ... create opaque member on initialization

- (void)foo
{
    opaque->cppobject.doSomething();
}
@end
Georg Fritzsche
Thanks, the other suggestions didn't seem to work and I ended up declaring my object as an "id*" then casting it to the correct type everywhere I wanted to use it. This seems like the same idea, but is much cleaner since I don't have to do all the extra casts.
Winder
I'd always prefer opaque pointers over casts - it might be a bit more work, but you get full type safety back.
Georg Fritzsche
I've been playing with opaque pointers for this, which I use extensively for C/C++ wrapping, but so far I haven't seen the real benefit. Can you compare this style (along with some code showing how "opaque" is allocated and released) to the void* based style here: http://robnapier.net/blog/wrapping-c-objc-20
Rob Napier
*Note:* Rob Napier posted a nice [update](http://robnapier.net/blog/wrapping-c-take-2-1-486) on wrapping C++.
Georg Fritzsche