Re: Strategies to prevent class name clashes
Re: Strategies to prevent class name clashes
- Subject: Re: Strategies to prevent class name clashes
- From: Arne Scheffler <email@hidden>
- Date: Sat, 16 Feb 2008 19:14:05 +0100
On Feb 16, 2008, at 5:42 PM, Jens Alfke wrote:
On 15 Feb '08, at 3:42 AM, Arne Scheffler wrote:
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.
I'm confused — is this a problem of collisions between C++ classes
or Obj-C classes?
If the C++ code is statically linked into each plugin, then it can't
conflict between multiple plugins. Each one will be directly calling
its own copy of the code, even if the C++ classnames and namespaces
are the same.
Objective-C classes _will_ conflict between multiple plugins, if
they have the same name. So what you have to do is make sure that
every plugin that statically links shared Obj-C code renames the
classes with unique prefixes. Basically, any time you write an Obj-C
bundle or framework, all the classes in it need to have a unique
prefix, whether or not you wrote those classes yourself.
It sounds like what's happening to you is that some of your classes
load out of your bundle and some get loaded from another plugin, and
these mismatched classes are passing C++ object pointers between
themselves. So when code from one plugin allocates a C++ object
(with one version of the C++ code), and then code from a different
plugin receives a pointer to that object and tries to operate on it
using a different version of the C++ code, you go boom.
But that's not a C++ specific problem. As soon as you have parts of
different versions of a library loaded and calling into each other,
there will be trouble. I've had this happen with Obj-C and pure C
code as well. You have to uniquify your Obj-C class names to avoid
this.
The problem is Objective-C. As written earlier this toolkit is used by
more than a hundred different plug-ins from different manufactures who
all may add some patches by their own to the C++ classes. The toolkit
consists of a few files which will be added to the xcode project of
the plug-in. So there's no shared library the plug-in links to. This
toolkit is also cross platform, currently working on Windows and Mac
OS X (Carbon). There were ports for classic Mac OS, BeOS and Motif in
the past.
So there are a few wrapper classes to wrap platform specifics. For
Cocoa I needed to make a subclass of NSView. The implementation of
this class needs to call some of the C++ classes. If there's another
plug-in loaded which also uses the toolkit it's likely that the
objective-c class is using the wrong vtable of some of the C++ classes
when they were modified.
Apple already knows about this problem since they removed HIToolbox
from the 64-bit version of Mac OS X. And they acknowledged it.
After digging deep into the runtime of objective-c I think it should
be fairly easy to support some kind of two level namespaces for it. I
hope that they will add something like that in the next major version
of os x. But for now I needed a working solution, which I found by
creating the objective-c classes at runtime.
arne
_______________________________________________
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