In article <miLRVB10w165w@csource.oz.au> david@csource.oz.au writes:
> I'm somewhat puzzled as to why the current rule on calling pure virtual
> functions from a base class does not simply prohibit them from being
> there (ie. by a compiler error) rather than defining the results as
> being 'undefined'. (ARM sec 12.7)
The reason is that it is quite legal to have a definition of a pure
virtual function, thus ...

class A
  {
    // ...
      ~A() { purefunc(); }
      virtual void purefunc() = 0;
  };

void A::purefunc()
{
  cout << "You called a pure virtual function !\n";
}

This facility might be useful when you want your abstract base class to
provide some kind of default behaviour, but you want to force derived
classes to add additional behaviour (or, at least, hint strongly :-).

> What is interesting to note is how the various compilers handled it.
> MSC/C++ 7 calls a null function via the vtable (cute), resulting in
> a system crash or main() being re-entered depending on memory model,
> but even more interesting is gcc 2.2.2 (djgpp), which generated a call
> to abort() inline and threw out the original code completely! In other
> words, it clearly knew that the code was wrong, but it silently did
> this, even at -Wall.
It looks like g++ is being clever, and making undefined pure virtual
function entries in the vtable point to a piece of code that does an
abort.

Good idea - are you listening Microsoft ? [Answer : Not officially :-]

Actually, it occurrs to me that it should be possible to do this yourself,
without adding to code size (probably) - just declare your virtual
functions ...

class A
  {
    // ...
      ~A() { purefunc(); }
      virtual void purefunc() = 0;
  };

inline void A::purefunc() { assert(0); }

Pure virtual functions can only be called explicitly, under circumstances
where the actual type can be deduced at compile time, which are the
conditions allowing inline virtuals to be expanded inline. Then again, I
could be wrong.

[This doesn't make you a smeg-head :-]
--
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) nikki@trmphrst.demon.co.uk
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.