On Fri, Jun 22, 2012 at 5:23 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Robert Ramey wrote:
Dave Abrahams wrote:
I mean, if there is a problem with boost::throw_exception or any other part of Boost Exception, I'd like to know about it.
It seems clear to me from his posts that Robert wants to talk about the process and has forgotten any specifics about actual problems.
The problem was the gratuitious inclusion of a new dependency.
Emil has described repeatedly why the change was not gratuitous. That you fail to recognize the value in the change does not make it gratuitous.
I looked at a recent boost/throw_exception.hpp. It includes boost/exception/detail/attribute_noreturn.hpp. That creates a dependency inversion that is unfortunate.
Obviously this is separated in a header with the prospect of becoming an official Boost header. OTOH, this functionality didn't exist, which presumably means that nobody else needs it. (I do not see the "dependency inversion" as a problem.) The header also conditionally includes the non-trivial
boost/exception/exception.hpp, another dependency inversion, which defines many types and functions, and includes some inline function definitions
Sure, that's what headers do. :) Pretty much all of this header is implementation details. The bit that concerns the user is that it's a couple hundred lines of self-contained code with absolutely no external dependencies.
If BOOST_EXCEPTION_DISABLE is not defined, then boost::throw_exception() tacks on Boost.Exception features to the exception being thrown.
This is a non-trivial set of changes to make to the top-level header.
It's non-trivial in that it enables the library to function. It's trivial in terms of cost and backwards compatibility. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode