Re: How is @selector resolved at compile time ?
Re: How is @selector resolved at compile time ?
- Subject: Re: How is @selector resolved at compile time ?
- From: Chris Kane <email@hidden>
- Date: Thu, 26 Jul 2001 10:50:31 -0700
On Wednesday, July 25, 2001, at 07:53 PM, Erik M. Buck wrote:
Suppose I have several different frameworks that all use a particular
selector
via @selector(someSelector). How do the compiler and runtime make sure
that
@selector(someSelector) always results in the same value (pointer) in
separate
compilation units in separate frameworks ? Are selector values that
result
from @selector somehow fixed-up when a framework is loaded ?
Yes. You can see objc-sel.m in the objc4 project in Darwin. This might
be described as: "the tentative values for the selectors emitted by the
compiler are fixed up at load time to refer to the values uniqued
through a binary search table and hash table".
In addition to @selector(), the compiler is also emitting selectors into
the binary as a result of class definitions.
Fun fact: in a typical Cocoa application there are ~12000 selectors,
plus or minus a few thousand.
They would have
to be to make sure that all frameworks in a running application have
the same
value for the same selector. How could that fix-up be implemented ?
Does
every occurrence of @selector result in a lookup at run-time each time
it is
encountered ?
No, as Greg explained, just a "global variable" reference at run-time.
No passing through a hash table or anything "during execution"; that's
done once at load time.
Chris Kane
Cocoa Frameworks, Apple