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

Subject: Re: [boost] [function] function wrapping and exception safety recap
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-10-11 14:53:18

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 the
other motivation for unsafe_function: the simplest way to work
out-of-the-box in RTTI-free environments is to remove the exception
safety guarantee, which these users do not want to begin with.

Daniel Walker