On Wed, Aug 20, 2008 at 10:07 AM, Robert Ramey <ramey@rrsd.com> wrote:
Peter Bartlett wrote:
Quoting Robert Ramey <ramey@rrsd.com>:
I'm not sure that is the right characterization. By default Boost works with standard C++ so if RTTI is turned off, then it is fair to require the BOOST_NO_TYPEID define. Changes such as this which potentially change "latent" bugs in client code/setup being turned into visible bugs have to be acceptable when changing Boost version, IMO.
My complaint is the imposition of a new requirement. This changes the "contract" between the library and its user. You can't change the contract and say that the code which used the old contract had "latent" bugs in it.
I have no idea what else this might break.
It will break people using throw_exception but throwing things not derived from std::exception. This was an implicit requirement anyway,
What is an "implicit requirement"? You mean that previous users of boost/throw_exception where remiss if they didn't derive from std::exception or if they didn't surround throw_exception with #if BOOST_NO_TYPEID. I like to think I'm a smart guy but I don't claim to be telepathic.
The implicit requirement was that any exception passed to boost::throw_exception must derive from std::exception. This has always been a requirement but it wasn't enforced before. It is enforced now and this did catch a few violations of this requirement.
but users will have previously got away with it if they never actually exercised their code on a no-exceptions platform.
Hmmm - It looks to me that the previous code would work fine on a no-exeptions platform - all it did was call a user defined throw_exception function.
Which takes std::exception. That's why it is required to derive from std::exception.
I can't think of any other problems, though. What did you have in mind?
LOL, That's the problem. I can't think of any problems because to do so would require investigating the new library in more detail would cost me more time than I have available right now.
The reason why the library integrates with boost::throw_exception is to allow the user to take advantage of the new facilities without requiring changes in any library that throws exceptions. Granted, for something as central as throw_exception, this has to be done very carefully and I think your concern is that this wasn't the case. Note that we don't have test failures in any library due to this new behavior of boost::throw_exception. Of course, if you can think of any problems or potential problems I'm very much interested to know about them.
This was not a problem then throw_exception had a very limited and well defined purpose. The real problem is creating a new library with new functionality and requirements and assigning to an old name which heretofore was being used for something else. This kind of thing creates a lot of unnecessary work for innocent bystanders.
I'll ignore the unsubstantiated claims and I'll just point out that boost::throw_exception has the same purpose it did before: it throws the exception you pass to it. The only difference is that now any exception that emanates from Boost can be transported between threads and can transport any data to the catch site. Consider that without the new boost::throw_exception behavior, for a user to take advantage of the new Exception library, it would be required to change all Boost libraries that throw exceptions.
IMO, the major issue with this change is the lack of documentation. Specifically,
http://www.boost.org/doc/libs/1_36_0/libs/utility/throw_exception.html
seems to refer to the 1.35 version of the code. I don't know if this a documentation bug or a documentation generation bug.
well, there is that as well.
The function is well documented, see http://www.boost.org/doc/libs/1_36_0/libs/exception/doc/throw_exception.html. Even if the new documentation was not available, the old documentation is 100% accurate because the semantics of boost::throw_exception have not changed at all. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode