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.
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.
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. 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.
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.