Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.lang.c++
Subject: Re: Efficient compilation of virtual functions
Message-ID: <1311@lupine.NCD.COM>
Date: 24 Aug 90 05:22:36 GMT
References: <1990Aug22.193347.18486@ux1.cso.uiuc.edu> <6428@wolfen.cc.uow.oz>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 61

In article <6428@wolfen.cc.uow.oz> pejn@wolfen.cc.uow.oz (Paul Nulsen) writes:
+nelson@suna2 (Taed Nelson) writes:
+
+> ...
+>If we have a virtual member function in the base class, and the same member
+>  function is redeclared in the subclass, whenever we are using an instance
+>  of the subclass, there is _no need_ to consult the virtual function table
+>  since we will _always_ call the subclass function. 
+> ...
+>	base *basePointer = new base;
+>	subclass *subclassPointer = new subclass;
+>	base *indirectPointer = new subclass;
+
+>	basePointer->mutate();
+>	subclassPointer->mutate();	// this should be optimized/inlined
+>	indirectPointer->mutate();
+
+This is not as straightforward as you suggest: subclass may have another
+class derived from it, in which case subclassPointer->mutate() is ambiguous
+and must be resolved via the virtual function table.
+
+The problem then is that the compiler needs to know that subclass has
+nothing derived from it. This is not possible with separate compilation.

This whole issue is rather interesting.

If I may, I'd like to refine Paul's final statement to say that "What the
compiler need to know is that it is not possible for the given pointer to
point to an object of a yet more derived class."

Paul is correct that this can be a virtually impossible thing for the
compiler to know in cases where the pointer variable itself is either
(a) a file-scope variable with external linkage, or (b) a parameter
to the current function whose value is being passed in from God knows
where.

Note however that in the example given by Taed, the pointer variable in
question was local to the function, and a simple bit of data flow analysis
could have helped the compiler to establish (unambiguously) that the given
pointer variable would *never* take on a value which pointed to any "more
derived" class.

Many (most?) optimizing compilers do perform at least some flow analysis,
so it would seem that de-virtualizing some calls on some virtual functions
should be both possible and reasonable.

This looks like it could be a potentially fertile type of C++ specific
optimization which future C++ compilers may implement.  On the other hand
(and until the day when lots of optimizing C++ compilers do this) it might
be useful (for time critical things) to provide both virtual and non-virtual
member functions (which do the same thing, but which have slightly different
names) in derived classes (calling the non-virtual one only when you are
sure that the non-virtual one will do what is needed).

Humm... sounds bad stylistically.... too error prone.  OK.  Forget I said that.
:-)
-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.