kicad-developers team mailing list archive

[al davis <ad10@...>]

On Wednesday 24 February 2010, Wayne Stambaugh wrote:
> Private virtual methods in C++ are not exposed and therefore
> are not require a vtable entry for each derived class. This
> design enforces this pattern. The compiler can (should?)
> optimize out the base class DoDrawLine(). If you make all
> of the methods public and virtual, each derived class's
> vtable links to the base class's vtable. There is a
> performance penalty for each vtable link and a size penalty
> for each vtable entry. This may be less of a problem with
> modern C++ compilers but it still exists to some extent
> because the public virtual methods vtable has to be exposed
> since the compiler doesn't know ahead of time if any derived
> classes need to access the base class virtual methods. I
> agree that it is a bit more cumbersome to write.

Can you provide a reference on this?

"private virtual" doesn't make sense to me, but the wx code is 
"protected virtual" which does make sense.

The use of the wrapper DrawLine forces all external calls to go 
through the virtual mechanism. Without it, in some cases the 
virtual mechanism would be bypassed. At the same time, it 
allows the internal DoDrawLine to call down the tree of base 
DoDrawLine, to implement an inherit and augment design.

Since DrawLine is expanded inline, there is no run-time 
overhead.

The vtable exists once per class, and contains the entire list 
of functions, so I don't see that overhead you refer to. Well 
.. one pointer, but that isn't worth worrying about. It's not 
per instance.

I did a speed test some years ago and found that the speed cost 
of a virtual is no worse than the speed cost of a real function 
call. The most significant speed cost of a virtual is that it 
prohibits inlining. Given that there is a decision involved 
with every virtual, I found that use of virtuals was never worse 
than any other way of making the decision.