This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why does debugging "pure virtual method called" have to be so hard?
- To: jbuck at synopsys dot com
- Subject: Re: Why does debugging "pure virtual method called" have to be so hard?
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Tue, 27 Oct 1998 10:13:37 -0800
- CC: jbuck at synopsys dot com, oliva at dcc dot unicamp dot br, jason at cygnus dot com, mrs at wrs dot com, egcs at cygnus dot com
- References: <199810271754.JAA16953@atrus.synopsys.com>
- Reply-to: mark at markmitchell dot com
>>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:
Joe> What if we have something like virtual void f () throw (Foo,
Joe> Bar) = 0;
Joe> There are always two possibilities: the specification allows
Joe> __pure_virtual_exception to pass, or it does not. So the
Joe> ideal compiler would generate one of the two calls. If we
Joe> can't tell or we are lazy, it would be better to make
Joe> mistakes in favor of not throwing (so the optimizer won't
Joe> make bad code), so a simple thing would be to generate the
Joe> _nothrow version if there is any throw specification at all.
But, this yields somewhat odd semantics. The whole point of throwing
an exception from a call to a pure virtual function would be to allow
the program to catch it, and do something sensible! IMO, this is
getting over-complicated.
Joe> The _exit(-1) could be easily changed to abort(), and people
Joe> debugging the problem could still set a breakpoint on
Joe> __pure_virtual. Maybe that one-line change is the one we
Joe> should really make.
This sounds right to me.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com