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

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

On Thu, Oct 7, 2010 at 8:06 PM, OvermindDL1 <overminddl1_at_[hidden]> wrote:
> On Thu, Oct 7, 2010 at 1:48 PM, Emil Dotchevski <emil_at_[hidden]> wrote:
>> 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).
>
> That 'feels' compile-time based, requiring a check, the first email is
> indicating something where there is no check at all, all done at
> compile-time, that is what I find most useful.

Right, unsafe_function provides no guarantee of how it will behave
when it has no target, and in fact, it does not check if it is
initialized before attempting to call its target. Hence the name
"unsafe." And you're also correct that users can choose between a
strong exception safety guarantee or no exception safety guarantee by
selecting different types of function object wrappers, either
boost::function or unsafe_function, at compile time. However, the two
wrappers are cross-constructable (and swappable), so you can also
change exception safety levels at runtime. For example,

void do_stuff(boost::function<int(int)> f)
{
    // ...
    if(f) {
        // Remove the exception safety guarantee for this block.
        boost::unsafe_function<int(int)> g = f;
        for(int i = 0; i < INT_MAX; ++i)
            g(i);
    }
    // ...
}

Emil's suggestion does something similar by changing boost::function's
exception safety guarantee, but do we really want to change
boost::function's exception safety guarantee? ... For one thing, given
an instance of boost::function, you would have to find out how it was
constructed in order to know its semantics. However, if the new
exception safety level is provided through an alternative wrapper, you
can simply look at the type of a wrapped function to know its
exception safety guarantee. So, in this case, I would prefer to extend
the Boost.Function library through a new function object wrapper,
rather than altering the semantics of boost::function.

Daniel Walker