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: Fri, 15 Feb 2008 13:35:24 +0100
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:
This email sent to email@hidden