Re: Cocoa and dead-code stripping
Re: Cocoa and dead-code stripping
- Subject: Re: Cocoa and dead-code stripping
- From: Chris Hanson <email@hidden>
- Date: Mon, 2 Jul 2007 10:46:52 -0700
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.
If I were writing a single application then the incremental size of
the code might not be a big deal. In my case it could be as much as
80x the incremental size.
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.
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.
The main caveat to this approach is that you will need to carefully
design your framework's API so that you can maintain binary
compatibility from release to release, if users aren't required to
upgrade all of your plug-ins at once. This isn't all that hard with
Objective-C since the only area where it suffers the fragile base
class problem is in instance size (number and size of ivars); you can
add methods all you want without affecting binary compatibility with
your framework's clients, unlike with C++.
In summary:
* Dead-code stripping isn't meaningful for Objective-C.
* Static libraries, plug-ins, and Objective-C don't mix.
* Frameworks are great if you're aware of the fragile base class
problem take it into account in your API design.
Hope this helps!
-- Chris
_______________________________________________
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