RE: AU, Obj-C and names
RE: AU, Obj-C and names
- Subject: RE: AU, Obj-C and names
- From: Blue Cat Audio Dev <email@hidden>
- Date: Fri, 02 Oct 2009 21:56:08 +0200
You are welcome. That's just the beginning of your troubles though
:)... Maybe the macro-based approach could be faster if time to market
matters. It depends on how often you intend to update your products as
well as the number of products you will have to maintain in parallel.
I also remember a trick used by the wxWidgets team using assembly
instructions to dynamically change ObjC class names at library load
time, but it's more a hack than a long term solution. If you are
curious you may want to have a look at it (www.wxwidgets.org - wxCocoa
port).
Anyway it's definitely an annoying limitation of Objective C as far as
plugins are concerned. Maybe the forced migration to full Cocoa apps
will encourage the Objective C team to add features to the language to
overcome this limitation.
The dev team
Blue Cat Audio
www.bluecataudio.com
Quoting john smith <email@hidden>:
Yes, of course, creating the Cocoa classes dynamically could fix the issue...
Great, thanks a bunch for the reply.
And yes, you're right, using a framework is not a solution I'm
prepared to use. There's reasons why the library is static in the
first place :-)
Thanks again, this was a great help to me.
Michael Olsen
Yes it is indeed a tricky issue. If your SDK APIs are stable enough
then you may
want to share them as a framework as suggested by someone else on this
list. But it's usually painful to maintain, so it's most of the time
not an option.
We were in a similar situation when porting our plugins to Mac last
year. So we ended up having all our Cocoa classes generated
dynamically (in runtime, using the objective C runtime apis: you
create the classes, add Objective C methods that call C functions
etc...) so that class names are unique to a plugin. It's kind of
strange to work with at the beginning but since everything in our
framework is wrapped into C++ classes it's not a problem once
implemented. Just be prepared to deep dive into the implementation
details of Objective C...
Another option is to use Macros to define unique names for every
plugin (AND every new version). It's much simpler but might be
difficult to maintain in the long run.
Hope this helps.
The dev team
Blue Cat Audio
www.bluecataudio.com
Quoting john smith <email@hidden>:
>
>
> Hi,
>
> so, looks like I cannot fight it off any longer... I have to move
> the rest of my code to Cocoa.
>
> But... I just found this:
>
>
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingCode/Tasks/NameConflicts.html
>
>
> Now, I have a SDK which I use myself, and also other companies are
> using it. This SDK builds a static library, which is linked with the
> plug-in.
>
> So, when I'm fully supporting Cocoa in this library, it seems that
> I'll have to deliver a new static library for each and every one of
> the plug-ins that are using it, just to avoid name clashes. It feels
> like I'm missing something here. Surely, this cannot be true?
>
>
> (Note that I'm only using Obj-C inside the library, the library
> interface is C++, and will stay that way).
>
>
> Thanks,
>
> Michael Olsen
>
> _________________________________________________________________
> Invite your mail contacts to join your friends list with Windows
> Live Spaces. It's easy!
>
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
_______________________________________________
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
_________________________________________________________________
Drag n? drop?Get easy photo sharing with Windows Live? Photos.
http://www.microsoft.com/windows/windowslive/products/photos.aspx
_______________________________________________
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