|
Boost : |
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-07-05 18:10:19
Dean Michael Berris wrote:
> On 7/6/06, Emil Dotchevski <emildotchevski_at_[hidden]> wrote:
>>
>> Please let's keep this to the point. There are no const_casts in the
>> proposed Boost Exception library. If you think that the dynamic_cast
>> can be avoided, I'm very much interested to hear how. If you think
>> the need for dynamic_cast is a result of poor library design, I'm
>> very much interested to hear about any improvement ideas.
>>
>
> Right now, I still haven't thought of a way to use some other facility
> aside from dynamic_cast<> but my point is more for abstraction and
> readability on the client code. The added abstraction will also allow
> you (and whoever will think of a way for bypassing the use of
> dynamic_cast) to change the implementation without having to worry
> about client code breaking.
>
> I'll probably do some of my own tests to figure out a way of possibly
> implementing the intended behavior without resorting to using a
> dynamic_cast<>. But for now, my concern remains to be the API by which
> the exception lib will be used/presented.
>
> It will also make the documentation much more readable and more
> informative IMO (and easier on the eyes) by removing the
> dynamic_cast<> and putting it in a macro/template abstraction. If the
> documentation didn't ever mention the use of dynamic_cast<>, then the
> users wouldn't even try attempting a dynamic_cast<> by themselves
> (unless they actually want to read the abstraction layer providing the
> functionality, which is a very rare case) -- and I for one wouldn't
> make too much a fuss about it.
One thing is clear, get_exception_info wouldn't make much of a difference,
and it would save me from having to explain why a dynamic_cast is alright
here, so fine, I'll add get_exception_info. :)
--Emil
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk