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
>> > 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk