Re: [boost] [function] function wrapping with no exceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping with no exceptionsafetyguarantee
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-12 03:44:38

At Mon, 11 Oct 2010 14:19:31 -0400,
Daniel Walker wrote:
> 
> On Mon, Oct 11, 2010 at 10:43 AM, Domagoj Saric
> <domagoj.saric_at_[hidden]> wrote:
> >
> > "Daniel Walker" <daniel.j.walker_at_[hidden]> wrote in message
> > news:AANLkTikdt4Cx9QcqeUX=SZ9rB8uqrmaahLpfMgxtEkTv_at_mail.gmail.com...
> >
> >> I have to say that I don't find the idea of gutting the current
> >> implementation to be particularly attractive. Boost.Function is
> >> already proven and familiar, and there's more we can still do with it.
> >
> > We can do more with it w/o 'gutting' it? I'm sorry I do not understand why
> > unsafe_function does not constitute 'gutting' while my changes do...note
> > that 'my' function requires no macro or a different name and is backwards
> > compatible with existing code (it only needs to be recompiled)...
> 
> My patch is very simple, and there are very few changes to the
> existing code. It uses the existing preprocessor metaprogramming
> infrastructure of Boost.Function to generate the same implementation
> code for both boost::function and unsafe_function with one small
> exception: The guarantee that operator() throws when it has no target
> is removed from unsafe_function. So, the vast majority of the
> implementation (type-erasure management, etc.) is unchanged.

I'm sorry if I missed something important here, but has everybody
really considered the consequences of Peter Dimov's post, where he
wrote:

> This example implies that unsafe_function is inherently more
> efficient, but this need not be so. An empty function may point to
> throw_bad_function_call instead of NULL.

One could swap out throw_bad_function_call for any behavior you like.

> > <snip>
> > However, here http://lists.boost.org/Archives/boost/2010/01/160908.php you
> > can see results that show a measurable difference when function<> is
> > configured to mark itself as nothrow...
> 
> The goal of unsafe_function is not to provide a wrapper that doesn't
> throw, but to provide a wrapper with no exception safety guarantee.

If that's *really* its goal, unsafe_function is strictly unneeded.
boost::function already satisfies all your requirements (and more).  I
think if you're looking to supply motivation for unsafe_function,
you'll need to describe the goal differently. ;-)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com