|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-09-07 11:26:03
"Iain K. Hanson" <ikh_at_[hidden]> writes:
> David Abrahams wrote:
>
>>"Iain K. Hanson" <iain.hanson@[...].com> writes:
>
>>> dynamic_cast needs rtti afaik, at least on some compilers e.g. Sun.
>>>
>>> My mention of incurring cost was to MI over SI. a quick test shows that
>>> throwing a exception using MI and virtual bases with gcc 3.2.2.5 with
>>> -O4 produces an assemblers file more than twice the size of of the same
>>> program using SI exceptions only. With a line count difference of nearly
>>> exactly double.
>>>
>>> That is a significant overhead for every exception.
>
>>Where is the overhead? Compile time? Runtime? Static data? Size of
>>intermediate assembly file ;-> ?
>
> hehe I'm an old hand assembler programmer and I probably assumed to much.
>
> There is, of course a compile time overhead. If you generate twice as much code
> then it will of course take longer. This is almost certainly I/O dominated and
> in practice is negligable.
>
> I have not done a full analysis of the output as this would take several hours
> but form a quick read through there is a small ( relative to the Code segemnt )
> Data segment overhead for additional book-keeping and the rest is code
> ( active instructions ).
What does "active instructions" mean? Are these instructions executed
when no exception is thrown? Are these instructions generated even
when the class is not used as an exception? Are they in functions
which are linked away unless used? Are the functions used by
exception hanlding, RTTI, or something else?
> I have no idea without doing a full analysis what proportion of the
> instructions actually execute and what are just code bloat.
>
> Which ever way you cut it, virtually inheriting from std::exception
> has a real cost to support an outside case of using MI for
> exceptions.
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.
-- 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