(1)

Sean McBride <mailto:s...@rogue-research.com> wrote (Wednesday, February 23, 2011 11:55 AM -0500):

2) You can keep C++ out of your Obj-C .h files like so:

#ifdef __cplusplus
typedef SomeCPPClassPtr SomeCPPClassRef;
#else
typedef void* SomeCPPClassRef;
#endif

Sean,

That's what I original thought of doing (or something similar), but was hoping there was a cleaner way. If this is the way to go, then I could probably be make this into a preprocessor macro so I could simply declare my instance variables like so:

@interface MyCPPClass : NSobject
{
    OBJCPPDECL(SomeCPPClass) *someCppObject;
    ...

where OBJCPPDECL(SomeCPPClass) would evaluate to id or void in Objective-C.

(2)

Ken Thomases <mailto:k...@codeweavers.com> wrote (Wednesday, February 23, 2011 12:41 PM -0600):

It might be better to follow the pImpl (pointer-to-implementation) pattern. The interfaces which need to wrap C++ functionality but be imported to
Objective-C code would not put any implementation detail (like the real
instance variables) into the interface.  Instead, the interface would have a
single instance variable, a pointer to the implementation data.  In the
interface, the pointer type is opaque.  It only gets defined in the
implementation.

Ken,

That's another excellent suggestion, although I'm loth to maintain all of the instance variable in a substructure.

(3)

It also occurred to me that if I'm careful, the Objective-C code doesn't really need any of the details of the instance variables in the Objective-C++ class:

@interface MyCPPClass : NSObject
{
#ifdef __cplusplus
    @private
    SomeCPPClass *someCppObject;
#endif
}
- (void)doSomething;
@end

So if the C code never accesses any instance variables directly, or defines a subclass of this class, or calculate the size of the object, etc., then it should function just fine in complete ignorance of its internal structure.

(4)

I've also considered that this abstraction could also be accomplished using a formal protocol or ABC:

@protocol MyCPPProto <NSObject>
- (void)doSomething;
@end

All of the C code that interfaces with MyCPPProto would do so through id<MyCPPProto> variables. While this is "correct," I suspect it would also become cumbersome.

(4)

Another trick would be to create an abstract base class that didn't have any of the CPP instance variables, define a concrete subclass in Objective-C++ with all of the additional details, then use a class cluster to create instances of the subclass. The Objective-C code would only include the header for the base class, and never have any knowledge of the subclass' details.

The drawback here is that things could get complicated if there's a hierarchy of Objective-C++ classes.

-

Personally, I'm leaning towards #3. It encapsulates all of the considerations in the Objective-C++ class' declaration, and all of my Objective-C code can treat all of my Objective-C++ objects as first class citizens.

So does anyone have experience maintaining mixed Objective-C/Objective-C++ code like this?

Also, I'm still curious to know if I should be using extern "C" when importing Objective-C headers in a Objective-C++ modules?

--
James Bucanek

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to