Re: Strategies to prevent class name clashes
Re: Strategies to prevent class name clashes
- Subject: Re: Strategies to prevent class name clashes
- From: glenn andreas <email@hidden>
- Date: Fri, 15 Feb 2008 09:13:28 -0600
On Feb 15, 2008, at 5:42 AM, Arne Scheffler wrote:
Hi Uli,
the toolkit in question is VSTGUI. It's a C++ cross-platform UI
library. It is statically linked into every plug-in. Mostly the
users of it won't use Objective-C by them self.
The problem I did face was that I have an ivar which is a C++ class
of the lib. And when I used this ivar and the C++ object had a
different layout than at build time it crashed. Here's an outline of
what I mean :
This is the class "Fragile Base Class" problem that plagues C++.
There are a few strategies to avoid this (search the web for ideas),
but they often get more complicated than is practical to implement -
re-implementing SOM is not something that you'd really want to do.
After thinking about it a while I think I need to write C functions
which will interact between the C++ class and the Objective-C class.
After all this Cocoa change is a headache for plug-ins.
This problem is a C++ problem - not that Objective-C doesn't have
that problem, but it is much rarer (in Objective C you can add method
to a base class without breaking things, which you can't safely do in C
++ since that alters the vtable layout, though adding ivars can also
break things). Objective-C 2.0 also addresses this problem, but I'm
guessing you can't require that.
There are also work-arounds for the Objective-C plugin namespace
collisions, but those require a fair amount of experience with both
the runtime and the mach-o file format. The basic strategy is to take
the binary in the plugin, make a copy, and edit the names of the
classes in the file to avoid collisions (walk the sections, find the
objective-c information, walk the modules to find the class
definitions, and then find the corresponding class names in the
strings table, and edit the strings table accordingly - this, of
course, is for Objective-C 1.0). Even this approach isn't foolproof,
since there may be a collision between a class in the plugin that you
rename that is also referred to in a nib file (which will then get the
non-plugin version of that class).
The safest solution is to launch your plugins in their own executable
space (using a simple host "nub") and use DO to communicate between
the plugin and the host. This isn't as fast, but it is much safer and
reliable (since you can even have a plugin crash and not take down the
host app).
At the very least, you'll want to review:
<http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingCode/Concepts/Plugins.html
>
and
<http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingCode/Tasks/UsingPlugins.html
>
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | prime : build, mutate, evolve, animate : the next
generation of fractal art
_______________________________________________
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