Boost logo

Boost :

Subject: Re: [boost] [function] function wrapping with no exception safety guarantee
From: Emil Dotchevski (emil_at_[hidden])
Date: 2010-10-07 15:48:07

Another solution is to define a different constructor of
boost::function which initializes it in a way that it doesn't throw,
similar to the constructors I added some time ago to support
allocators. So you could just say

Emil Dotchevski
Reverge Studios, Inc.

On Thu, Oct 7, 2010 at 12:19 PM, Daniel Walker
<daniel.j.walker_at_[hidden]> wrote:
> Hi all,
> A few weeks ago, there was a request to remove boost::function's
> dependency on boost::throw_exception when the user ensures that
> boost::function is always initialized before attempting a call.
> Providing an alternative invocation method in addition to the call
> operator is an unattractive solution for many reasons; e.g.
> boost::function would be less function-like syntacticly. Instead, why
> not provide an alternative function wrapper with no exception safety
> guarantee and no dependency on boost::throw_exception?
> Thanks to Boost.Function's implementation design, which uses
> preprocessor metaprogramming to generate many function wrappers with
> different arities, it is simple to generate a function wrapper with no
> exception safety guarantee. I have submitted a feature request with a
> patch that implements boost::unsafe_function -- a function wrapper
> with no exception safety guarantee -- along with tests and updated
> documentation.
> unsafe_function's API and semantics are identical to boost::function
> except that the behavior of operator() is undefined when
> uninitialized. Also, swap, constructor and assignment operators have
> been added to allow an unsafe_function to wrap the target of a
> boost::function and vice versa.
> unsafe_function is primarily useful in certain environments in which
> exceptions and/or compiler optimizations are unavailable, such as some
> embedded systems. On contemporary PC hardware, unsafe_function
> typically would not have an advantage over boost::function. For
> example, with object code generated by gcc -O2, I could only detect a
> ~1% difference between the two in terms of runtime costs using a
> simple benchmark; i.e. less than a nanosecond. However, with -O1,
> unsafe_function costs ~15% less than boost::function due to the lack
> of overhead from the strong exception safety guarantee.
> Thoughts?
> Daniel Walker
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at