public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Joe Buck <jbuck@synopsys.com>
Cc: jason@cygnus.com, mrs@wrs.com, egcs@cygnus.com
Subject: Re: Why does debugging "pure virtual method called" have to be so hard?
Date: Tue, 27 Oct 1998 03:02:00 -0000	[thread overview]
Message-ID: <orww5mhom9.fsf@araguaia.dcc.unicamp.br> (raw)
In-Reply-To: <199810262017.MAA17869@atrus.synopsys.com>

I wrote:

>> ... calling a pure virtual function has undefined behavior ...

Joe Buck <jbuck@Synopsys.COM> writes:

> which means we can do what we want.

> I vote for
> 	throw __pure_virtual_exception;

> where that class is derived from class std::exception.

The more I think of it, the more I dislike this too...  Given the
following code snippet:

class foo {
  virtual void bar() = 0;
  foo() {
    try {
      bar();
    } catch (...) {
      // do something
    }
  }
};

It would seem strange to have an exception caught in this case...  Of
course, the behavior is undefined, so we can do whatever we want, but
it just sounds too unexpected to me...  Also, unlike calling abort(),
this wouldn't help debugging very much.  OTOH, by throwing an
exception, it would become possible to redefine the behavior of
calling a pure virtual function, and try to work around failures,
which is something one might want to do.

It seems to me that a better solution would be to implement
__pure_virtual in a way similar to terminate and unexpected, i.e., by
providing a default implementation that abort()s, but allowing the
user to modify this behavior by running __set_pure_virtual() or
something like that.  The default pure_virtual handler could be
abort(), and we could provide an alternate handler, say
__pure_virtual_throw, that would throw
__pure_virtual_exception (: public std::exception).

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:oliva@gnu.org mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil


  reply	other threads:[~1998-10-27  3:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <199810160157.SAA17725.cygnus.egcs@kankakee.wrs.com>
1998-10-16  0:09 ` Jason Merrill
1998-10-26  2:13   ` Alexandre Oliva
1998-10-25 23:42     ` Jason Merrill
1998-10-26 13:42     ` Joe Buck
1998-10-27  3:02       ` Alexandre Oliva [this message]
1998-10-26 20:11         ` Joe Buck
1998-10-27 14:55       ` Mark Mitchell
1998-10-27 16:33         ` Joe Buck
1998-10-27 16:33           ` Mark Mitchell
1998-10-29  0:50           ` Why does debugging "pure virtual method called" have to be sohard? rich_paul
1998-11-01 15:00           ` rich_paul
1998-11-02  7:12             ` Martin von Loewis
1998-11-02 22:42               ` rich_paul
1998-10-27 18:13       ` rich_paul
1998-11-03 21:28 rich_paul
1998-11-04 20:47 ` Why does debugging "pure virtual method called" have to be so hard? Jeffrey A Law
  -- strict thread matches above, loose matches on Subject: below --
1998-11-02 11:56 Mike Stump
1998-10-28 12:45 Wegher, Jeff
1998-10-16 13:29 John Lindal
1998-10-16 11:28 John Lindal
1998-10-15 18:57 Mike Stump
1998-10-16  4:10 ` Lassi A. Tuura
1998-10-15 16:00 John Lindal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=orww5mhom9.fsf@araguaia.dcc.unicamp.br \
    --to=oliva@dcc.unicamp.br \
    --cc=egcs@cygnus.com \
    --cc=jason@cygnus.com \
    --cc=jbuck@synopsys.com \
    --cc=mrs@wrs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).