Boost logo

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. :)


Boost list run by bdawes at, gregod at, cpdaniel at, john at