RE: pure virtual w/implementation bug in GCC 3.3?

[Eljay Love-Jensen <eljay at adobe dot com>]

Hi Lyle,

Note:  we're getting off topic for the subject of this thread of conversation.  If we continue, we should probably change the subject line.

Virtual functions can be inlined.

Some old compilers had problems with inlined virtual functions.  I think those days are ancient history.

There is an issue with some compilers when ALL virtual functions are inlined.

The reason why is because many compilers use the strategy of generating the virtual function pointer table when it sees the first non-inlined function generated -- the "blessed" non-inline virtual function..

Since the "blessed" non-inlined function is (usually) only generated ONCE, in some module (or compilation unit), this strategy is normally a good way to assure that there isn't wasted space with loads of virtual function pointer tables being generated helter-skelter.

If all virtual functions are inlined, then there is no "first non-inlined virtual function" which to "bless".

One strategy for this situation is to generate virtual function pointer tables in all modules (compilation units), and then trust the linker to weed out duplicates.  I think this is the strategy used by GCC for C++ programs.

Another (bad!) strategy is to not generate any virtual function pointer table at all.  My old DEC C++ compiler did this.  Very annoying.  The workaround was simple: generate a "do nothing" private virtual function that wasn't inline.  But still a kluge.

I don't think any modern C++ compiler follows the "punish the prorammer for valid code" strategy these days.

There can also be an issue when using member function pointers when the function is inlined.  GCC assists in that unfortunate (and relatively uncommon) situation with the -fkeep-inline-functions flag.

Sincerely,
--Eljay