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

Subject: [boost] [function] function wrapping with no exception safety guarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-10-07 15:19:20

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