Re: including xibs from another project
Re: including xibs from another project
- Subject: Re: including xibs from another project
- From: Roland King <email@hidden>
- Date: Wed, 20 Jan 2010 23:47:56 +0800
ok this makes some sense, there's lots of ways in which I can see dynamic resolution of classes or methods isn't known at link time, KVO, methods composed from strings, I would not expect a linker to figure that out. But that's not where we are in this example, it's a little more direct than that, there's a class Foo and if you call
[ Foo anyMethod ]
all the code for Foo gets linked in
but if you call
[ foo anyInstanceMethod ]
where foo is explicitly defined to be a Foo*, it doesn't link it in.
In that case the method selectors and class names do appear in the library, at least otool can figure them out, the variable is of a known type, the selector is defined. The call in the code is for a selector anyInstanceMethod on an instance of a known class Foo, it's quite possible that the code may actually present an object which is a subclass of Foo, and it's also possible that that subclass of Foo may not call [ super anyInstanceMethod ] but that seems to be a little unlikely, surely most likely if you have an instance defined as a Foo* and you call a method anyInstanceMethod on it, it's likely that you're going to need the code for anyInstanceMethod on class Foo either directly or through a super class call and probably for the rest of the class Foo too so why would you not link it in?
This particular case seems pretty easy to see to me, there's no funky selector magic or dynamic classes, the code calls a method on a Foo*, link the Foo code ..
On 20-Jan-2010, at 11:24 PM, Fritz Anderson wrote:
> On 20 Jan 2010, at 7:12 AM, Roland King wrote:
>
>> I do understand by the way why -all_load works around this, I just don't understand why my instance method calls aren't enough to cause the linker to pull code in and I need class method calls.
>
> Objective-C is a dynamic language. Method calls get dispatched to actual code only at run time. The caller's method selectors and class names may not even appear in the source code; with key-value coding and run-time class creation (both EXTREMELY common, even if you don't use them yourself), method and class names may get composed at run time from formatted strings. Even if the method name were known to a certainty, there is (effectively) no class hierarchy to identify the class to which the method belongs, nor whether you intend to use a class that just happens to implement a method of the same name; and so there is no way to know whether a class is used.
>
> When your code is compiled and linked, the compiler and linker have no way of knowing whether any message send will end up in your library. By static-language rules (which the gcc tool chain assumes), the library's classes look unused, and they don't make it through dead-code stripping. If you want a class to be included in your application, you have to say so explicitly.
>
> — F
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden