Re: Why does debugging "pure virtual method called" have to be sohard?

[rich_paul at bigfoot dot com]

It seems that with this much differance in desired semantecs, the only way
to make everyone happy would be the following pair of functions:

typedef void (*handler) ();
handler __set_pure_virtual_handler ( handler h );
void __default_pure_virtual_handler ( void );

This would be consistant with ::operator new, and would allow one to
specify whatever behavior their little heart desires for their handler.

My suggestion would be to throw an exception, perhaps as suggested below,
or perhaps __gcc::pure_virtual_exception, I don't know if that's permitted
by the standard, but it would be nice to have the compiler specific stuff
in one namespace if we're allowed to.  If we did that, perhaps
__gcc::set_pure_virtual_handler and __gcc::default ... would be in order.

If someone could tell me the place that I'd have to hook ( where you get
to if and only if there is a pure virtual function called ) I'd be willing
to write the class and the code.  I don't know very much about the
internals of gcc, but apart from changing the function called to a call
down a function pointer, there doesn't seem to be much internal work to
do.

--------
Where do you want to crash, toady?
On Mon, 26 Oct 1998, Joe Buck wrote:

> 
> > Calling a pure virtual function is not a case of exception handling,
> > so it might be strange to call it in such a situation.
> 
> This is too bad.  I wish the committee had specified that an exception
> be thrown here; it would be consistent with the rest of the language.
> Everywhere else, if the user does something illegal that can't be caught
> at compile time (e.g. bad dynamic cast of a reference), we throw an exception.
> 
> > ... calling a pure virtual function has undefined behavior ...
> which means we can do what we want.
> 
> I vote for
> 	throw __pure_virtual_exception;
> 
> where that class is derived from class std::exception.
>