Re: [boost] Gauging interest in patch submissions

Subject: Re: [boost] Gauging interest in patch submissions
From: Hongli Lai (hongli_at_[hidden])
Date: 2011-09-29 02:39:05

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_at_[hidden]
Chamber of commerce no: 08173483 (The Netherlands)