[boost] Re: Virtual inheritance in exception hierarchies

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-04 19:12:17

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

> On Tue, 2003-09-02 at 19:32, David Abrahams wrote:
>> "Iain K. Hanson" <iain.hanson_at_[hidden]> writes:
>> 
>> >> But is this a good design?  It certainly isn't the only possible one.
>> >> (Making all the code depend upon the definitions of both Network_err and
>> >> File_system_err - which no doubt drags other stuff into the translation unit
>> >> - isn't a design choice I'd make lightly.)
>> >
>> > In certain places it may be the most natural design choice. Whether it
>> > is a good idea to pay for virtual inheritance in every exception derived
>> > from class exception is a separate issue. Exception handling incurs a
>> > significant cost once an exception is thrown. Adding to that cost could
>> > drive more users away from exception handling.
>> 
>> Do you think dynamic downcasting through a layer of virtual
>> inheritance is significantly more expensive than downcasting through a
>> layer of regular inheritance?
>
> I don't know as I have not benchmarked it. However, it will incur a
> penalty and also has a size penalty. On some compilers it may mean
> turning on RTTI which often reduces optimisation and increases general
> code bloat.

This rings of FUD.  I don't believe it neccessarily has to incur a
penalty over a dynamic_(down)cast through non-virtual bases and I
don't believe there are *any* compilers which will require RTTI to do
EH with virtual bases but will work with EH, no RTTI and non-virtual
bases.

>> 
>> > Also, I'm not sure that this use case is sufficiently common to burden
>> > all exceptions with.
>> 
>> What's the burden?
>> 
>> I'm just askin', is all.
>
> Space and time overhead. There are still people out there who will not
> use exceptions for performance reasons ( perceived or real ). Anything
> we do that increases the cost will give them further excuse.

That's their choice.  I don't think Boost should cater to incorrect
assumptions of inefficiency.

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