Re: [boost] [function] function wrapping with no exception safety guarantee

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
boost::function<void()>(foo,nothrow).

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

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.
>
> https://svn.boost.org/trac/boost/ticket/4646
>
> 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.
>
> https://svn.boost.org/trac/boost/ticket/4720
>
> 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: http://lists.boost.org/mailman/listinfo.cgi/boost