Re: Advice for Cocoa Plug-ins & Objective-C implementation uniquing
Re: Advice for Cocoa Plug-ins & Objective-C implementation uniquing
- Subject: Re: Advice for Cocoa Plug-ins & Objective-C implementation uniquing
- From: Blue Cat Audio Dev <email@hidden>
- Date: Tue, 02 Feb 2010 10:36:42 +0100
Hi there,
this limitation of Objective C (no local namespace for libraries) is
indeed painful... For our own plugins, we have studied several ways to
overcome it (some already mentioned in this thread):
1. using a shared framework: the versioning/install hassle seemed too
much overhead to us.
2. using Macros depending on plugin name: probably the fastest and
most convenient way, but becomes unusable as soon as you have many
Objective C classes. Not very elegant either... :)
3. using objective C runtime to generate classes at runtime: that's
the one we chose. The main drawback is that you can't use the
Objective C syntax anymore (just using C calls to call dynamically
generated objects). But in our case that's not a problem since we
maintain a set of C++ classes for platform abstraction so that our
plugins work on several platforms.
Option 3 is an investment but it's really worth it if you are never
using your Objective-C classes directly and you have a large code base
to maintain (you do the work once and then forget about it). It's also
an easy way to map C++ classes to Objective C abstractions (you map
objective-C methods to C functions). If you are Mac only and do not
have too many classes in your framework, then option 2 might be th way
to go.
Hope this helps! Not sure if there are other options... Someone from
Apple maybe? Any "official" recommendation? With audio apps coming to
the 64-bit world, this is going to be a common problem for plugin
developers!
G.
Blue Cat Audio
www.bluecataudio.com
Quoting Kyle Sluder <email@hidden>:
On Mon, Feb 1, 2010 at 10:13 AM, Jonah Petri <email@hidden> wrote:
How do other folks deal with this?
We statically link some code into our Automator actions, so we
encounter the same scenario. We abuse the preprocessor a bit by
compiling with a flag such as -DPLUGIN_NAME=MyPlugin and using code
like this:
#ifdef PLUGIN_NAME
#define MyClass PLUGIN_NAME_MyClass
#endif
@interface MyClass : …
--Kyle Sluder
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden