On Thu, Feb 25, 2010 at 9:33 PM, Eric Niebler <eric@boostpro.com> 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