Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!ucsd!dog.ee.lbl.gov!pasteur!galileo.berkeley.edu!jbuck
From: jbuck@galileo.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.c++
Subject: Re: >>> Virtual functions and inline ...
Message-ID: <11611@pasteur.Berkeley.EDU>
Date: 2 Mar 91 17:50:42 GMT
References: <ssimmons.667836666@convex.convex.com>
Sender: news@pasteur.Berkeley.EDU
Reply-To: jbuck@galileo.berkeley.edu (Joe Buck)
Lines: 60

In article <ssimmons.667836666@convex.convex.com>, ssimmons@convex.com (Steve Simmons) writes:
|[ Is it okay to declare virtual functions inline ? ]

!>      If
|> 	the routine is either too complicated or a virtual function,
|> 	then a static copy of the routine will be placed in the 
|> 	compiled module.   Thus, a routine that was coded as inline 
|> 	may cause a performance degradation because it may consume
|> 	much more space when it is not physically inlined.

Many implementations will do this, but all that's really necessary
is that the virtual function table have a pointer pointing to a
single copy of the virtual function.  If you can arrange to generate
only one copy of the virtual function table per class, then you
have no waste.

cfront 2.0 attempts to do this by a heuristic: generate the vtable
in the object module that contains the definition of the first
non-inlined virtual function.  This heuristic would work perfectly
except that functions can be declared inline outside the class body,
so there's more work (or more kludges) required to make the scheme
work.

As of 1.37.2, g++ introduced "#pragma interface" and "#pragma
implementation", a non-portable way of assuring that you only get
one vtable and one copy of inlined virtual functions per class.
There's been some discussion of implementing the cfront trick,
but this would make g++ virtual function calls as inefficient as
they are in cfront.

In an article in the C++ Journal describing the cfront scheme, the
authors quote the old chestnut "every problem in computer science
can be resolved by adding another level of indirection", and that's
precisely what they do -- in cfront you don't get a pointer to the
vtable in an object, you get a pointer to a pointer to the vtable.
Of course, you pay a cost for this on every function call.

|> 	With a virtual function, a copy of that routine will be 
|> 	created for every module that has at least one instantiation 
|> 	of that class. 

See above; not true in either cfront or in g++ (if you're willing
to use #pragma).

|> 	The language allows it but you would not be deriving any 
|> 	better performance.  I have become very negative 
|> 	towards the inline feature of a language like Ada's inline
|> 	pragma or C++'s inline definition.  After all, inlining is 
|> 	not part of the algorithm, just a performance enhancement. 
|> 	Inlining should be done as part of the optimizing phase.

Perhaps, but with separate compilation it's difficult to do inlining
as part of optimization.

Still, during development I think it's a good idea to avoid inlining
except for trivial one-liner functions.

--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck