Dean Michael Berris wrote:
On 7/6/06, Emil Dotchevski <emildotchevski@hotmail.com> 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