Re: Instance Variable access
Re: Instance Variable access
- Subject: Re: Instance Variable access
- From: Allan Odgaard <email@hidden>
- Date: Mon, 10 May 2004 02:33:46 +0200
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).
You can do something like:
this->Base::foo();
But that's not really different than the version w/o 'this'.
There are some hidden branches in the ObjC-version, because it is
run-time linked and thus goes through a Mach-o stub.
That whooshing you hear is the sound of that last sentence going over
my head. :) I don't know what a Mach-o stub is.
objc_msgSend is in a shared library. Your executable needs to call
that function, but doesn't know the location in the shared library
(which may change from version to version). So instead it calls a stub
function, this stub function will read the pointer from a table and
jump to the address found there (although the first time the stub is
called, it is not the actual function, but one responsible for loading
it, and updating the table).
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
but it seems to me Objective-C *could* use a vtable-type
implementation [...]
No, this is not possible without some very huge method tables,
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.
[...] 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 ;)
Furthermore there is the problem of having code compiled in different
environments arrive at the same index numbers for the same method.
I wouldn't think that would be a huge problem if SEL values are
generated as necessary at class-load time.
And that is again, how it currently works. I.e. the name is converted
to a SEL at run-time (and possibly cached). 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...
:)
_______________________________________________
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.