Re: Strategies to prevent class name clashes
Re: Strategies to prevent class name clashes
- Subject: Re: Strategies to prevent class name clashes
- From: "B.J. Buchalter" <email@hidden>
- Date: Fri, 15 Feb 2008 15:16:31 -0500
On Feb 15, 2008, at 11:53 AM, Bill Bumgarner wrote:
In general, it is considered odd that a set of plugins would
statically link in the shared UI driver bits. Doing so increases
memory footprint and can be exceedingly problematic unless the
functionality within each plugin is maintained in total isolation.
It is -- the functionality within each plugin is maintained by
thousands of developers world-wide. Arne is trying to develop a Cocoa
compatibility layer for a C++ UI framework, that I expect would not
require any changes to the C++ side of the client code for those
thousands of plugins. I am guessing that this is being driven by the
fact that 64-bit Carbon was dropped and that there is a desire, long
term, to support 64-bit in VST hosts...
In the audio world, the plugins have generally carried around
statically linked versions of their glue and UI code. It hasn't been
exceedingly problematic until we start to factor in the need to
integrate with Cocoa.
Best regards,
B.J. Buchalter
Metric Halo
http://www.mhlabs.com
_______________________________________________
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