on Wed Aug 27 2008, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
David Abrahams:
So IIUC, your intention was never to require RTTI in throw_exception, ...
The new throw_exception was not supposed to impose any new requirements and it certainly was not supposed to break code that worked before. (It almost succeeded at that.)
and Emil didn't know that, so he violated your original intent unwittingly. What about the "weight" of the header and its dependencies? Your usual stance is to avoid such things.
Well, one upside is that exceptions thrown by boost::throw_exception now can be used with boost::exception_ptr. This makes exception_ptr more useful and requires zero effort from library authors who already throw all their exceptions via boost::throw_exception.
I understand the benefits. You've completely avoided my question ;-) What about the "weight" of the header? Did imposing it on clients of boost::throw_exception concern you at all? If you went through some cost/benefit analysis (even in your own mind) I'd like to hear about it.
The alternative way to provide such functionality would've been through a separate throw replacement, part of Boost.Exception. This would indeed have had zero impact on the rest of Boost, both in the negative and the positive sense. (That is, it would have required every library author willing to support exception_ptr to switch from boost::throw_exception to the new function.)
Yes, I understand that too.
It was impossible to predict in advance whether going with option A would be worth the trouble. The only way to find out was to try.
Surely there must be another way to find out if library authors would react badly to a dependency on Boost.Exception. In fact, it might well have been possible to sell everyone on the idea before the fact, but it will be a lot harder to get Robert to accept it now.
I think that (for such a major change) the transition went fairly smoothly. We still have the option to revert throw_exception if the "broad discussion" that should have happened then but is happening now reaches this conclusion.
I'm not sure it's the right conclusion to reach, but I do want to discuss it.
Either way, we'll still be ahead of where we were, both because we now have BOOST_NO_RTTI and some awareness of its significance, and because the new throw_exception caught a few bugs.
The impression I get is that for you, those benefits outweigh the costs by such a wide margin that the costs aren't even worth mentioning. Is that right? -- Dave Abrahams BoostPro Computing http://www.boostpro.com