Re: Help Mixing Objective-C & Objective-C++
Re: Help Mixing Objective-C & Objective-C++
- Subject: Re: Help Mixing Objective-C & Objective-C++
- From: James Bucanek <email@hidden>
- Date: Wed, 23 Feb 2011 13:35:13 -0700
(1)
Sean McBride <mailto:email@hidden> 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:email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden