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 15:20:25

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.

Undefined behavior is desirable when there are performance or
portability problems with defining a behavior. No such problems exist
with the current boost::function semantics. You can't both want
undefined behavior and be against any particular behavior, such as
throwing an exception or calling a function.

The only viewpoint from which this discussion makes sense to me is
that it might be beneficial to remove the coupling between
boost/function.hpp and boost/throw_exception.hpp, although as
suggested by Nevin this still doesn't address the question of what
happens if a constructor fails to establish the boost::function
invariant.

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