Re: Strategies to prevent class name clashes

FROM : Arne Scheffler
DATE : Sat Feb 16 19:14:05 2008

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