Re: Cocoa and dead-code stripping
Re: Cocoa and dead-code stripping
- Subject: Re: Cocoa and dead-code stripping
- From: Steve Christensen <email@hidden>
- Date: Mon, 2 Jul 2007 12:59:44 -0700
On Jul 2, 2007, at 10:46 AM, Chris Hanson wrote:
On Jul 2, 2007, at 9:46 AM, Steve Christensen wrote:
I'm currently working with around 80 application plug-ins I've
written that link against this static library. All the plug-ins
use a number of features, plus each plug-in individually uses
various other features, depending on what it specifically
requires. So come link time, the linker strips out all the pieces
a particular plug-in isn't using. No magic there.
Going forward, I'm working to move my UI (and selected other
pieces) to Cocoa. Given the number of builds I'm doing, I'd still
like to compile the common pieces once, including the Cocoa bits.
I'd also like to, ideally, not have a bunch of never-used methods
left in the binary.
As others have pointed out, "dead-code stripping" is not possible
for Objective-C because given both the semantics and common use of
the language, the linker cannot prove that any particular method
will never be called -- and in fact some methods are likely to
never be invoked from other code in your plug-in, but as a result
of an action defined in a nib.
I'd like to point out a further issue with what you're considering,
however: You have thus far been able to get away with using a
static library for this approach only because you haven't been
using Objective-C. Once you start using Objective-C, you will not
be able to use a static library, because while C++ classes are not
objects and have little associated runtime data structure
associated with them, Objective-C classes are objects and are
associated with substantial runtime data structures. You cannot
have the same class registered in the same runtime multiple times,
which is what would happen if you had two plug-ins link your static
library and get loaded into the same application.
This also seems to imply that class registration is by name, at
runtime? So when creating custom classes for various plug-ins, it
sounds like it would be a bad idea if they were all named
MyNiftyWindowController, since whoever registered first would be the
one all the rest of the plug-ins would reference.
I cannot recommend strongly enough that you create a
"FooSupport.framework" that contains the common code for all of
your plug-ins, and that you link all of your plug-ins against that
in the future instead of against a static library. Long-term this
will be the most supportable solution, and it completely avoids the
"multiple versions of the same class registered" problem.
Understood. I'll likely continue to leave the the non Obj-C pieces in
a static library and link against it since a lot of common plug-in
logic will remain in C++ classes and low-level Carbon.
Hope this helps!
Yes it did. Thanks, Chris!
steve
_______________________________________________
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