Adam Turoff wrote:
>
> On Tue, Jul 10, 2001 at 02:08:58AM -0500, David L. Nicol wrote:
> > Uh, C++ virtual methods can be overloaded on a per-object basis, not
> > just a per-class basis, since the object drags around its virtual jump
> > table with it wherever it goes, so the jump can get compiled into
> > "jump to the address that is <offset> bytes away from the start of
> > the object that is doing the method" which is pretty light, unless
> > you've got dozens of virtual methods.
>
> And what's the linguistic hook that allows C++ object-based inheritance?
> And where's the guarantee that vtbls are per-object and not per-class?
>
> Z.
Apparently I was basing my statements on an incorrect understanding.
According to a recent C++ reference,
http://www.icce.rug.nl/docs/cplusplus/cplusplus16.html#l269
> A common implementation is the following. An object containing virtual
> functions holds as its first data member a hidden field, pointing
> to an array of pointers holding the addresses of the virtual functions.
> It must be noted that this implementation is compiler-dependent,
> and is by no means dictated by the C++ ANSI definition.
>
> The table of addresses of virtual functions is shared by all objects of
> the class. It even may be the case that two classes share the same
> table. The overhead in terms of memory consumption is therefore:
>
> One extra pointer field per object, which points to:
>
> One table of pointers per (derived) class to address the virtual functions.
At this time, I do not know if I actually worked with a compiler that
implemented virtuals per-object, ot if I just thought that that was
how it did it.
Anyway, the scheme I described would be one way to do per-object method
overloading.
Letting the method that is
supposed to be overridable on a per-object basis look up the object
that is calling the method in a table keyed with object pointers
might be lighter than keeping a field in every object -- it would depend
what fraction of the objects of the type would get overloaded and how
many would keep the default, and the memory vs. speed trade-off.
I do not think the language needs additional cruft to support this;
I think it would be better handled in the implementation of the
accessor functions.
Wait for better tieing and reimplement.
--
David Nicol 816.235.1187
