On 7/9/06, Emil Dotchevski <emildotchevski@hotmail.com> wrote:
[snipped]
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 get_exception_info.
People use interfaces to allow for different implementation strategies. But the only implementation possible for get_exception_info is to use dynamic_cast!
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.
--Emil
regards, -- Felipe Magno de Almeida