• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Strategies to prevent class name clashes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strategies to prevent class name clashes


  • Subject: Re: Strategies to prevent class name clashes
  • From: Thomas Engelmeier <email@hidden>
  • Date: Fri, 15 Feb 2008 13:04:01 +0100


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.


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

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Strategies to prevent class name clashes
      • From: Arne Scheffler <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>)

  • Prev by Date: Re: Strategies to prevent class name clashes
  • Next by Date: Stacking views
  • Previous by thread: Re: Strategies to prevent class name clashes
  • Next by thread: Re: Strategies to prevent class name clashes
  • Index(es):
    • Date
    • Thread