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.
Options are either to
- use a common framework (+versioning) for the implementation (less
footprint)
or
- educate users to switch the symbol visibility for each and every
library symbol to private, meaning they will not be shared (more mem
footprint)
- or create an e.g. preprocessor based class naming scheme where e.g.
VSTUIClass will be replaced by VSTUIClass2_0
(once again, less footprint as all plugins share a 2.0 implementation,
only the ones using 1.9 will load another implementation..)
Especially for audio I'd go with a potentially shared implementation
as additional code might mean VM usage exceeding physical memory, i.e.
swapping...
Regards,
Tom_E
_______________________________________________
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
