Re: [boost] [exception] virtual inheritance troubles

Subject: Re: [boost] [exception] virtual inheritance troubles
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2010-02-26 03:24:36

On Thu, Feb 25, 2010 at 9:33 PM, Eric Niebler <eric_at_[hidden]> wrote:
> The trouble is that std::runtime_error does not have a default constructor,
> and that boost::throw_exception doesn't simply throw the exception passed to
> it; it throws an object of type of clone_impl<regex_error>. Because of the
> virtual inheritance, clone_impl needs to call std::runtime_error's directly,
> but it doesn't. It can't know to do that in general.

I'm attaching a patch with a rather ugly workaround for the problem. I
really don't like it but it is one possible solution.

An alternative solution can be to derive from clone_base and implement
cloning "manually". Unfortunately this would also require a
modification to throw_exception to detect when a type derives from
clone_base already and not inject it as a base (it does something
similar for the boost::exception type itself.)

I'm out of other ideas but I'm definitely interested to hear other
opinions about this issue.

> <aside>
> It actually doesn't seem to be particularly useful in this case to use
> virtual inheritance because std::runtime_error inherits from std::exception
> non-virtually. In order to avoid the pitfall described here
> <http://tinyurl.com/yb2jpns>, it seems *every* exception type in the
> hierarchy needs to use virtual inheritance, and that unfortunately is not
> the case for the standard exception hierarchy.
> </aside>

Yes, unfortunately. However, it seems like implementations should be
able to detect when the type being thrown could possibly lead to
ambiguities at the catch site and report a warning in this case? I
wonder if any compilers do this check.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode