🚀 go-pugleaf

In article <9997@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
|No, you're not missing anything.  That's the technique I'd use.  I
|wasn't aware that space consumed by a vtables was a big deal, except
|in those cases where the compilation-and-linking system produced many
|vtables for a single class (I've heard about that).  How big do
|vtables usually get, how often can they be shared, and (given a
|one-per-class implementation) how much space does this sharing usually
|save?

I guess I'm not convinced either that inability to share vtables is that
big a deal.  However, size of vtables can be limiting in the kind of 
programming that implements many many methods per class, and only changes
a few methods when deriving [ala Smalltalk.]   In such situations, vtable
costs can be large compared to the code size of the few methods being
changed.  For right now, C++ programmers avoid the problem by not using
such a coding style.  Eventually, smarter compilers may be necessary that
know how to dispatch methods using a variety of techniques automatically
chosen to match the situation.  A simple example: at the cost of an 
additional indirection, vtables could be broken into subtables, and the
common subtables shared between classes.  When a method is overridden,
only the subtable needs to change, not an entire vtable.  Still, I don't
think the situation comes up often today where a C++ programmer would be
willing to pay an additional indirection on every dispatch in order to get
smaller vtables.