On Mon, Sep 8, 2008 at 10:31 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
I don't know if this will be enough. For me the semantics has ben changed
Could you please elaborate on this? (Hint: one possible definition of changed semantics is that the current behavior of boost::throw_exception is incompatible with the the previously documented behavior.)
Robert has already created its own serialization::throw_ewception which is a copy of the old boost::throw_exception, who will be the next?
There are also Boost libraries that use throw directly, without calling any function. If there is a requirement for all Boost libraries to throw using boost::throw_exception, I'm certainly not aware of it. If users care about the benefits of the "new" boost::throw_exception behavior (if it stays, which is obviously subject to discussion), they will complain that the Serialization or some other library doesn't call it. If not, all is good. :)
IMO, we need to provide the old boost::throw_exception publically on boost, even if we change its name, before each library developer and user define its own throw_ewception.
What reasons do you have for avoiding the current throw_exception behavior?
Can you provide some performance results comparing the old and the new implementations?
1) The performance cost of the current boost::throw_exception compared to the previous boost::throw_exception is the added zeroing of 3 pointers and an int. 2) Even if there was a measurable degradation in performance, it only occurs if an exception is being thrown. Therefore, it has to be compared to the overall speed of propagating an exception up the call stack (hint: often, this is a rather slow process.) There are two valid concerns with the "new" boost::throw_exception: A) Source code bloat: throw_exception.hpp is a major coupling point in Boost and as such, anything included by it has the potential of being included by many libraries, and, due to the mostly header-only nature of Boost, by the end user. Here is some cold data: on my system, preprocessing throw_exception.hpp results in ~30,000 lines of code, of which the added weight of boost/exception/exception.hpp is ~400 lines. Of course, throw_exception.hpp itself doesn't do anything. Including something that's actually useful yet minimal -- for example intrusive_ptr.hpp -- equals ~40,000 lines of code; shared_ptr.hpp: ~55,000 lines. In this case, the overhead is < 1%. B) Maintenance problems: we've already seen one bug in throw_exception.hpp escape undetected by our testing process, until it was reported by the end users. Clearly, any change in boost/exception/exception.hpp has the potential of breaking many libraries which -- I know -- is a major headache. So what's the upside? - The ability to transport Boost exceptions between threads. - The ability to catch any (well, most) Boost exceptions. - The ability to augment active exception objects with important information that is relevant to the failure but is not available at the point of the throw. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode