GMan wrote:
My only concern with this is in a case like this, for example:
while (/* reading lines from file, parsing integers, otherwise ignoring*/) { try { myInts.push_back(boost::lexical_cast<int>(currentLineStr)); } catch (const boost::bad_lexical_cast&) // (has stack trace) {} }
Will the stack trace make such an operation noticeably slower? I know it's easy to retort with "don't use exceptions for flow control" but I believe my concern is valid, even if it's a bit contrived of a situation.
Perhaps we'd like to make it opt-in, like BOOST_THROW_EXCEPTION_TRACED or something.
I don't know what one considers "noticeably slower", but there will be overhead for sure. In our implementation, the creation of a tracable_exception object copies the current stack trace into itself. This may or may not be large depending on how many stack traces are defined. We've done our best to optimize our implementation but it's still an O(n) operation. There is one concern that I have with BOOST_THROW_EXCEPTION_TRACED. Will it affect the ABI? Suppose I compile against a Boost library that's installed on the system, and it was compiled without BOOST_THROW_EXCEPTION_TRACED. If I define BOOST_THROW_EXCEPTION_TRACED now will this change the exception hierarchy, and thus, the ABI? - Hongli -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: info@phusion.nl Chamber of commerce no: 08173483 (The Netherlands)