From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2006-07-09 03:22:45
On 7/9/06, Emil Dotchevski <emildotchevski_at_[hidden]> wrote:
> I agree with you in principle, but I believe this case is an exception to
> that principle.
> For the exception library to work, the object thrown by throw failed<T>()
> must derive from T and from exception_info. If it was some other library,
> there are other implementations possible: maybe to make exception_info a
> member, or whatever. But because the whole point is to be able to
> catch(exception_info &), and to catch(T&), the exception type must derive
> from both.
> Therefore users know that dynamic_cast will work, with or without
> People use interfaces to allow for different implementation strategies. But
> the only implementation possible for get_exception_info is to use
That is not the only reason. The implementation is just a detail from
a user point of view, things that expose that implementation become a
distraction to the user. Which, usually, dont care about how it is
done, as long it works as expected.
> Therefore, to me anyway, get_exception_info's purpose is to hide the
> dynamic_cast so I don't get emails like "why do you have a dynamic_cast as
> part of your interface". It's not part of the interface, it's part of C++.
> It does exactly what you need when you catch(T&) and want to see if you can
> get an exception_info *.
If a user has to use dynamic_cast to be able to use the library then
it is part of the interface too, IMO. And asking why seems to me like
a very reasonable question. Now, using dynamic_cast to implement the
library is not a problem, since it is not of my concern as a user.
As an example of good implementation hiding, boost::function uses
void* all over the place, albeit its interface is as clean and
straightforward as it can be. Even if void* is or isnt the only
implementation possible. I, as a user, do not have any interest in
glimpsing over any void* to be able to use boost::function.
-- Felipe Magno de Almeida
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk