The subject of this thread, and discussion of it both here and elsewhere, has suggested a closely related question:
When a static library is linked in, what classes within the static library are loaded, only the referenced classes, or all of them? One quick note -- regarding the -all_load linker option, if you have categories in your static library, you don't have a choice (on iOS) about using the -all_load option: Technical Q&A QA1490 http://developer.apple.com/library/mac/#qa/qa1490/_index.html ...otherwise you'll get a runtime error. I was of the understanding that only referenced (read: imported) classes in the static library get loaded. There are indications in Xcode 4, and several on the Apple developer forums that are saying otherwise, rather than linking loads all classes in the library regardless of imports. The answer to this question has pretty big ramifications in the design of static libraries, and the use of third party static libraries, because if using a static library by default inherits the loading of the entire library, that is definitely going to make me think twice about using any third party library, as it could have notable memory impact. If anyone can shed some light on this, that would be great. Brad On Apr 23, 2011, at 3:57 PM, Bradley S. O'Hearne wrote: > Thanks for the response, Stephen. I was under the impression that category > modification was limited to the types within which they are imported. Thanks > for expanding my knowledge of categories! > > Cheers, > > Brad > > On Apr 23, 2011, at 3:22 PM, Stephen J. Butler wrote: > >> On Sat, Apr 23, 2011 at 3:36 PM, Bradley S. O'Hearne >> <br...@bighillsoftware.com> wrote: >>> Since transitioning to Xcode 4, I have discovered a very curious shift in >>> the way Objective C categories are handled in static libraries. In general, >>> if you create an Objective C category, you have to import that category >>> into an implementation (.m) class in order for that category's additions to >>> be visible and used. That worked great in Xcode 3, as you can control what >>> categories methods appear wherever by merits of using the import (or not). >>> However, in Xcode 4, all categories defined in a static library used in a >>> dependent project are by definition visible, even if not imported. >> >> It's always been this way at runtime. When a category is loaded it >> changes the behavior of all instances of a class that it modifies, no >> ifs/ands/buts. It's loaded by the DYLD, and that has no concept of >> your imports/includes. From the Obj-C docs: >> >> ""Category methods can do anything that methods defined in the class >> proper can do. At runtime, there’s no difference. The methods the >> category adds to the class are inherited by all the class’s >> subclasses, just like other methods."" >> >> Now the tools, on the other hand, were less smart in Xcode3 and below. >> Autocomplete, IB message browser, etc only knew about the >> messages/properties visible to the immediate code block (via import, >> include, etc). That Apple has fixed this in Xcode 4 to better match >> reality is a GOOD THING. > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/brado%40bighillsoftware.com > > This email sent to br...@bighillsoftware.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
