Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!deimos.cis.ksu.edu!rutgers!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: address of virtual function (revisited)
Summary: Relative costs
Message-ID: <177@mole-end.UUCP>
Date: 9 May 89 06:22:28 GMT
References: <904@garya.Solbourne.COM> <6590114@hplsla.HP.COM>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 60

In article <6590114@hplsla.HP.COM>, jima@hplsla.HP.COM (Jim Adcock) writes:
> > It sure will.  Pointers to virtual members are themselves virtual and go
> > through the virtual tables.  ...  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 ...  The cost really isn't that great.
 
> Well, I find the cost somewhat discouraging ...
 
> class baseclass
> {
>     virtual int size(){return sizeof(baseclass);}
> };

>  . . .

> baseclassptr->size();

Not relevant.  This is pointer-to-object, NOT pointer-to-member.  Pointer-to
member isn't that common an operation:

	int (baseclass::*fn)() = &baseclass::size;

	i = (baseclass_obj.*fn)();
	j = (baseclass_ptr->*fn)();
 

> 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.

True, this could be better implemented ASSUMING you know that all functions
derived from this virtual member will be used in this way.

All in all, the 10X cost is a matter of half-a-dozen extra instructions.
Unless you can show that this is more than 2% of the cost of your program, I
advise you not to worry about it.
 
> 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.

C++ is still at least an order of magnitude faster of Objective-C, and
encourages this sort of interface.  Objective-C doesn't seem to.
-- 

(This man's opinions are his own.)
From mole-end				Mark Terribile