Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: address of virtual function (revisited)
Message-ID: <6590114@hplsla.HP.COM>
Date: 5 May 89 17:46:43 GMT
References: <904@garya.Solbourne.COM>
Organization: HP Lake Stevens, WA
Lines: 44

> It sure will.  Pointers to virtual members are themselves virtual and go
> through the virtual tables.  How, you ask, is it done?  Take my word, you
> don't want to know.  It's ugly.  Worse, it imposes a couple of extra
> instructions of cost on every call-through-a-pointer-to-member-function if
> the class has *any* virtual members (or perhaps its any virtual members whose
> argument signatures match; I don't know for sure.)  The cost really isn't
> that great.

Well, I find the cost somewhat discouraging if all one is trying to do is
return a value from an object of uncertain class.  For example, try to
find an inexpensive way to get a hierarchy of classes to return information
about their sizes -- presumably:

class baseclass
{
    virtual int size(){return sizeof(baseclass);}
};

class derivedclass : baseclass
{
    int size(){return sizeof(derivedclass);}
}


For these simple get-a-value, put-a-value type virtual access functions
one could hope for code that compiles to a simple double indirection:

baseclassptr->size();

compiles to:

baseclassptr->(vtable+offset_of_size)->a_constant_equal_to_size;

or maybe even:

baseclassptr->vtable[offset_of_size_constant]

The present approach gives code that is about 10X slower than one
would hope for in these simple, everyday cases.

Again, for OOP to be affordable, these simple, everyday "get" and
"put" type functionalities must be handled at minimal cost.
Otherwise programmers will violate strict encapsulation, and come
up with "hack" solutions.