[boost] [function] function wrapping and exception safety recap

Subject: [boost] [function] function wrapping and exception safety recap
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-10-09 15:38:00

Hi all,
While it's fresh on my mind, I just want to recap the previous
discussion and to make sure this is brought to Doug's attention.

http://thread.gmane.org/gmane.comp.lib.boost.devel/209304

To summarize, there have been several complaints from users who don't
use RTTI about boost::function's dependency on Boost.Exception.
boost::function has a strong exception safety guarantee and uses
boost::throw_exception to implement it. This affords users
sophisticated options as to how exceptions are actually thrown (or not
thrown in RTTI-free environments), since boost::throw_exception can be
defined/customized by the user. This is a great feature for some, but
others would prefer a function object wrapper that behaved more like a
function pointer; i.e. no exception safety guarantee and no RTTI
dependency. The following feature request and patch try to answer this
demand by adding a new function object wrapper to the Boost.Function
family of wrappers: boost::unsafe_function. boost::unsafe_function is
simple to generate with only slight modification to the code that
generates the existing boost::function/functionN family.

https://svn.boost.org/trac/boost/ticket/4720

Some concerns have been raised regarding the efficiency of the NULL
pointer check in boost::function's operator(), but I believe this is a
side issue at best and possibly a case of premature optimization. In
optimized object code, the overhead of the pointer check is so small
that it is difficult to detect (from simple benchmarks with MSVC
Release mode and gcc -02). Regardless, in circumstances where
aggressive compiler optimization is unavailable, unsafe_function could
be used to address this concern as well. (I measured a ~15% reduction
in time with gcc -01, for example.) Of course, as Peter and Emil
pointed out, one could eliminate the pointer check in boost::function
if its default "empty" state actually wrapped a valid function, e.g.
throw_bad_function_call(). This may be a good idea by itself, but
again, this is tangential to the present feature request to provide a
function object wrapper that is independent of boost::throw_exception
and RTTI.

Finally, there have been suggestions to alter boost::function's
exception safety guarantee directly through either policies or
constructor options. These solutions are functionally similar to
unsafe_function, so preferences between them may be a matter of
personal taste. Personally, I like having two distinct class templates
for two orthogonal levels of exception safety. Also, I like that
anytime I encounter an instance of boost::function, I know it has the
same strong exception safety guarantee it has always had, without
having to wonder how it was instantiated or constructed. So, in this
case, my preference is to expand the Boost.Function family of function
object wrappers, rather than alter boost::function itself.

Daniel Walker