Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!ark
From: ark@alice.UUCP (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: vtbl for abstract class : WHY ?
Keywords: abstract class, vtbl
Message-ID: <11253@alice.UUCP>
Date: 30 Aug 90 12:57:55 GMT
References: <2206@runxtsa.runx.oz.au>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 51

In article <2206@runxtsa.runx.oz.au>, tom@runxtsa.runx.oz.au (Thomas Antalffy) writes:
> When I make a class abstract by assigning 0 to one of its virtual methods, 
> my C++ compiler generates a virtual function table and puts the address of 

> 		char __pure_virtual_called() 

> in the appropriate slot. This later creates a link error, because there is 
> no default implementation of this function.

> I assume that this mechanism is there to give you the chance of putting 
> error handling in __pure_virtual_called().

No, there should be a __pure_virtual_called() in the library.
It, in turn, should print an appropriate error message and abort.

It's there because by chicanery it is possible to call a pure virtual
in circumstances a compiler cannot detect.  For example:

	class A {
	public:
		A();
		virtual void f() = 0;
	};

No problem so far, right?  You can't create an A object, of course.

	void callf(A* ap)
	{
		ap->f();
	}

Still no problem.  Since you can't create an A object, ap must in
fact point to an object of a class derived from A, which in turn must
have defined an f() member.

Now look at this:

	A::A() { callf(this); }

Again there is no way for the compiler to see what's wrong.
The callf function might just plug data members of A, in
which case it would be harmless.  What it actually does, of
course, is to try to call the nonexistent f() member of the
A object!

So you see the point.  In principle you should not be allowed to
call a pure virtual but you can by trickery.  It is better to obtain
a clear diagnostic in that case than a random crash.
-- 
				--Andrew Koenig
				  ark@europa.att.com