Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strategies to prevent class name clashes




On Feb 15, 2008, at 1:04 PM, Thomas Engelmeier wrote:


On 15.02.2008, at 12:42, 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. Here's an outline of what I mean :

You simply were lucky.
The OS X dyld loader not only loads Cocoa classes just one but also uses just the very first instance of any given symbol.
That means if one plugin loads the audio equivalent af libTiff2.4 and another the equivalent of libTiff2.6, they are likely to crash.
Or an plugin using boost 1.3.2 will affect the plugin with a fixed boost version 1.3.3. And it's the reason why an plugin cannot use the debug STL variant in an host using the nondebug STL implementation.



No, dyld as of Mac OS X 10.2 supports two-level namespaces. Otherwise AudioUnits and VST plug-ins wouldn't work on Mac OS X. As an example every VST plug-in just exports one C function and yet I haven't heard of a host only be able to load one VST plug-in.
I think what you mean is if some one tries to load a dylib and there's already a dylib with the same name in the process, than you're right it only loads the first one.
I'm talking about a bundle which will be loaded via CFBundleLoadExecutable.
At present, when not using Objective-C, if the dyld maps two different bundles into the process the symbols will be in separate namespaces so that there could be the same symbol twice and the names would not clash. Plug-in A will always call the right symbol even if plug-in B has a symbol with the same name.
With Objective-C now this won't work anymore.


Options are either to
- use a common framework (+versioning) for the implementation (less footprint)

How does framework versioning work for Cocoa ? If one plug-in got compiled with say version 1 and another got compiled with version 2. Will they both work ? How is that possible as Objective-C only allows one class with the same name ?


thanks
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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden
References: 
 >Strategies to prevent class name clashes (From: Arne Scheffler <email@hidden>)
 >Re: Strategies to prevent class name clashes (From: Lieven Dekeyser <email@hidden>)
 >Re: Strategies to prevent class name clashes (From: Uli Kusterer <email@hidden>)
 >Re: Strategies to prevent class name clashes (From: Arne Scheffler <email@hidden>)
 >Re: Strategies to prevent class name clashes (From: Thomas Engelmeier <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.