Re: Instance Variable access
Re: Instance Variable access
- Subject: Re: Instance Variable access
- From: Andy Lee <email@hidden>
- Date: Sun, 9 May 2004 22:39:11 -0400
On May 9, 2004, at 8:33 PM, Allan Odgaard wrote:
On 9. May 2004, at 2:20, Andy Lee wrote:
((Base *)this)->foo(); // also prints "base" (I think)
No, just as with ObjC, the dispatch happens at run-time, the typecast
is really just a run-time thing (as long as you only up- or downcast
the pointer).
Now that I look at it, what I was saying made no sense. Sigh.
I must have been thinking of constructors. I won't try to express the
rule precisely, because I'll just embarrass myself again, but the
principle was that an object can't invoke instance methods implemented
in a given class until it is guaranteed to be an internally consistent
instance of that class -- i.e., until that class's constructor has
finished. Part of the protect-me-from-myself design of C++.
[...explanation of Mach-o stubs...]
This is 'indirect addressing' and you can read about it here:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/
MachORuntime/2rt_powerpc_abi/chapter_9_section_6.html
Thanks.
That's assuming the method lookup table is an array like a vtable is,
which I didn't mean to imply. It just has to be a data structure on
which you can perform lookups, where the lookup key is some unique
surrogate for the method name and the returned value is a function
pointer.
But that's pretty much what it is now, although only the cache part of
it, but probably with good reason, as storing all the methods in the
table would just clutter it, since only a fraction are really used.
Actually, that's what I was thinking -- that all the messages a class
responds to could be stuck in its method-lookup table, where some of
the function pointers would point to inherited method implementations,
just as some function pointers in a C++ vtable point to inherited
implementations.
[...] The challenge then would to come up with a data structure that
uses reasonable space and a fast (though obviously not constant-time)
lookup algorithm.
Like the current use of hashing ;)
Sort of, but with the reminder that hash values per se are not used for
looking up a class's implementation of a method. The method-lookup
table uses a unique lookup key -- a SEL -- and not a hash value, which
is not guaranteed to be unique for all method names. The per-class
data structure for looking up the implementation for a given SEL should
be faster than a hash table, just not as fast as an array.
An actual hash table only makes sense for looking up the SEL that
corresponds to a given method name. I imagine this would be a global
master data structure that only gets used by the class loader and by
the NSSelectorFromString() function, with perhaps a reverse-lookup data
structure for NSStringFromSelector().
And that is again, how it currently works. I.e. the name is converted
to a SEL at run-time (and possibly cached).
By run-time do you mean the conversion is done at class-load time or
message-send time? As Ondra pointed out, hashing is *not* done at
message-send time; by that time, the runtime environment already has a
SEL in hand; there is no method name in sight.
From this, I assumed all string hashing is done at class-load time (and
during NSSelectorFromString()). I figured the class loader could go
through the names of all the methods in the class being loaded,
generate new SELs as necessary for method names we haven't seen before,
and update the method-lookup tables (the big ones I was talking about)
for all classes that are affected.
I am afraid I did not really get your point... i.e. you say that
ObjC *could* use a vtable-like system as C++, and then you apparently
suggest it should work exactly as it does now, but that is certainly
not how C++ works... :)
The thing that would be vtable-like was that the lookup table for each
class would be populated with function pointers for all message names
the class responds to, including inherited ones. There would be no
need to update the table during the act of sending a message. But
maybe the cost of doing repeated lookups in the larger table would
dwarf the saved cost of occasionally updating the table as needed. It
was just a thought.
--Andy
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.