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

Subject: Re: [boost] [function] function wrapping and exception safety recap
From: Emil Dotchevski (emil_at_[hidden])
Date: 2010-10-11 16:13:42

On Mon, Oct 11, 2010 at 12:57 PM, Daniel Walker
<daniel.j.walker_at_[hidden]> wrote:
> On Mon, Oct 11, 2010 at 3:20 PM, Emil Dotchevski
> <emil_at_[hidden]> wrote:
>> On Mon, Oct 11, 2010 at 11:53 AM, Daniel Walker
>> <daniel.j.walker_at_[hidden]> wrote:
>>> On Mon, Oct 11, 2010 at 2:45 PM, Daniel Walker
>>> <daniel.j.walker_at_[hidden]> wrote:
>>>> On Mon, Oct 11, 2010 at 2:05 PM, Emil Dotchevski
>>>> <emil_at_[hidden]> wrote:
>>>>> On Mon, Oct 11, 2010 at 10:45 AM, Daniel Walker
>>>>> <daniel.j.walker_at_[hidden]> wrote:
>>>>>> On Mon, Oct 11, 2010 at 2:49 AM, Nevin Liber <nevin_at_[hidden]> wrote:
>>>>>>> On 11 October 2010 00:01, Emil Dotchevski <emil_at_[hidden]> wrote:
>>>>>>>> On Sat, Oct 9, 2010 at 12:38 PM, Daniel Walker
>>>>>>>> <daniel.j.walker_at_[hidden]> wrote:
>>>>>>>>> Finally, there have been suggestions to alter boost::function's
>>>>>>>>> exception safety guarantee directly through either policies or
>>>>>>>>> constructor options.
>>>>>>>>
>>>>>>>> We used to have an Allocator parameter to the boost::function template
>>>>>>>> and it was removed (just in time for this change to also be reflected
>>>>>>>> in C++0x) to reduce coupling.
>>>>>>>
>>>>>>> So what exactly is the proposed behavior if the function object cannot
>>>>>>> fit in the small object optimization space of unsafe_function and the
>>>>>>> allocation fails?
>>>>>>
>>>>>> As proposed, unsafe_function has the same semantics as boost::function
>>>>>> with one (and only one) exception: the behavior of operator() is
>>>>>> undefined when it has no target.
>>>>>
>>>>> If that was the only motivation, you could just disable exception
>>>>> handling, and then define:
>>>>>
>>>>> namespace boost
>>>>> {
>>>>>  void throw_exception( std::exception const & )
>>>>>  {
>>>>>    assert(0);
>>>>>  }
>>>>> }
>>>>>
>>>>
>>>> Correct. But users have complained about this, which is exactly the
>>>> motivation for unsafe_function. It works out-of-the-box in RTTI-free
>>>> environments with no dependency on boost::throw_exception. It's a
>>>> simple problem really.
>>>
>>> P.S. Sorry I spoke to soon. That's not exactly correct. A user could
>>> do what you describe, but boost::function could not, since that would
>>> change its exception safety guarantee; i.e. it would no longer throw
>>> (or call a user definable function) when it had no target.
>>
>> This is not exception safety issue, it is a choice between defined and
>> undefined behavior.
>
> A strong exception safety guarantee is a defined behavior.

Any behavior fits "undefined behavior". Like I said, if someone wants
undefined behavior, they can't be against any particular behavior,
including throwing an exception.

> Another group of users, would like a function wrapper without coupling
> Boost.Exception, and indeed, without an exception safety guarantee.
> unsafe_function address the demands of this second group of users.

What is the problem with adding a constructor such that you could say:

boost::function<T>(f,std::nothrow)

This way, I'm pretty sure that as long a program only instantiates the
nothrow constructors, the resulting executable won't depend on
boost::throw_exception.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode