Comments on: Wrapping C++ in ObjC

By: Box2D UIView and Objective C C++ Wrapper | CocoaHeads

Box2D UIView and Objective C C++ Wrapper | CocoaHeads — Fri, 14 Jan 2011 19:38:58 +0000

[...] technique rapidement présentée est celle-ci : http://robnapier.net/blog/wrapping-c-objc-20. Le post est un peu vieux, et l’auteur de ce blog utilise depuis une autre technique, [...]

By: Rob Napier

Rob Napier — Wed, 09 Jun 2010 06:44:56 +0000

@Jacob, see my update. I've posted a simple example of this. I'll post a more complex example (including smart pointers, and more) shortly.

By: Wrapping C++ – Take 2, Part 1 | Cocoaphony

Wrapping C++ – Take 2, Part 1 | Cocoaphony — Wed, 09 Jun 2010 06:43:27 +0000

[...] year, I presented an approach to wrapping C++. Since then, I’ve been introduced to other approaches, particularly from gf who helped me [...]

By: Jacob

Jacob — Tue, 08 Jun 2010 09:01:35 +0000

Hi,

Any chance of reposting "http://pastebin.org/207012"? or providing an equivalent example of the non-trivial constructor here?

Thanks

By: Rob Napier

Rob Napier — Sat, 08 May 2010 16:56:24 +0000

OK, now I’m seeing it. The key is the use of C++’s ambiguity between structs and classes. By adding a “constructor” to your struct, you got the benefits of a C++ object while allowing it to be defined in the header. No casting at all, and fewer raw pointers to C++ objects. I should be able to wrap shared_ptr<> in there easily as well (which is coming up more often in my code, and has been a bit of a pain). I like this. I’ve got a dozen or so ObjC/C++ wrapper classes to write this month, so I’ll give this a try and see if it’s as handy as it looks. Thanks.

By: gf

gf — Fri, 07 May 2010 16:00:53 +0000

I somehow forgot about this discussion, sorry about that. Snippet here: http://pastebin.org/207012

For me it has the major advantage that through the wrapping opaque struct i’m in a clean C++-world again regarding object storage.

By: Rob Napier

Rob Napier — Tue, 23 Feb 2010 17:44:25 +0000

I’m not clear how you’re allocating the object for the struct if it has a non-trival constructor (i.e. you need to pass parameters). Can you show an example of this model? As far as helper C++ objects, I have them all the time (mostly listeners), but I don’t see what that has to do with a struct. They don’t need to be passed around as some kind of bundle; I just have multiple pointers in my ObjC class. Again, maybe this would be clearer with some example code of using the opaque pointer.

By: gf

gf — Tue, 23 Feb 2010 08:10:32 +0000

@Rob Napier Thanks for the heartache point, that might be a good one (i've currently mainly done rather flat Obj-C bridging). But there is no additional malloc/free/new/delete - its still one as you don't need to hold a pointer to the object in the opaque struct.

I think we have a misunderstanding though, i didn't intend to hand the opaque pointer aound, its just for Pimpl.

Putting other things in there is not only relevant if you pass the pointer - what if you need to additional (helper/secondary) C++ objects to deal with the main object?

By: Rob Napier

Rob Napier — Mon, 22 Feb 2010 14:34:36 +0000

You should never call "opaque->cppobj" directly. That access an ivar (opaque) outside of an accessor, which should be avoided whenever possible. There is no single rule that will avoid more heartache then sticking to accessors, and the caller shouldn't need a special "oh, I use the ivar directly when it's a C++ wrapper" rule. Special rules are the bane of code review. So in any case it'll be "self.opaque->cppobj" which is no better than "self.cppobj," while adding an additional malloc/free for the struct.

To the point of putting other things in the struct, this is only significant if you ever hand back pointers to the struct to a caller, and you almost certainly shouldn't be doing that anyway in ObjC. This makes sense in a C wrapper around C++ (like Core Foundation, and I use this pattern elsewhere), but I still don't see a benefit in ObjC.

Do you have any example code that shows how to do this well without bypassing accessors on the ivars? I think the resulting code is less space efficient, more complicated and gives no greater type safety.

By: gf

gf — Sat, 20 Feb 2010 19:39:59 +0000

gf :The only down-side i can think of is the pointer-indirection in high-performance code – but that can get possibly optimized if there is a proven hot-spot there

Hm, but then the "void*"-pointer approach has also one indirection and it has another advantage - you can just put more members in the struct, without any visible change to the clients. So the only overhead i can possibly see is maybe padding of the struct.