[boost] Re: Virtual inheritance in exception hierarchies

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-08 06:29:03

"Iain K. Hanson" <ikh_at_[hidden]> writes:

>> I'm open to the idea that MI should be banned in exception hierarchies
>> as an alternative to using virtual inheritance.  I don't think
>> non-virtual multiple inheritance can be justified, though.
>
> Ouch! Lets not throw the baby out with the bath water. ( if you'll excuse 
> the pun :-). ). 

No, really, let's.  We can't afford to keep the baby without the
bathwater.

> I'm very definately *not* anti MI. I find the netfile_err example a
> very natural and intuitive use of MI. What I am unsure of is the
> recommendation that we should always virtualy inherit from
> std::exception.

Do you understand the problem?  If netfile_err's two bases each has a
distinct std::exception base class (likely), then
catch(std::exception&) will fail to catch a thrown netfile_err.  That
seems like a terrible risk to take with something that only happens
at runtime, and then only extremely rarely.

> Which leads me to the realisation that I have been testing the wrong thing.
> I should have been testing virtual versus non-virtual SI and not SI versus 
> MI. 

Right.

> I'll do some more tests tomorrow and post preliminary results but to answer 
> definatively and in detail would require a large amount of work on my
> part and would be specific to a particular version of gcc and a specific
> optimisation level.
>
> What I would really like is to here from some of the compiler writers that 
> lurk here and preferably several so that we could understand the general cost
> of virtual inheritance when there is only SI and in the context of exceptions.
>
> Is there any way you could prod some of them?

I'm afraid I'd need to be prodded to prod them.

Y'see, I'm not very interested in the answer because in general those
costs are going to go into the same bit bucket that all EH goes into:
it's a cost which you incur at runtime iff an exception is thrown, and
in code space in the translation unit *where* it's thrown.  There's
really no other possibility, since catch(std::exception&) clauses
don't need to see all the classes derived from std::exception in order
to do their work.  It's fairly easy to localize and minimize those
costs, and anyone unwilling to pay them should probably turn off EH
altogether.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com