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@gmail.com> 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