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

Subject: Re: [boost] [function] function wrapping and exception safety recap
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-10-11 18:55:29

On Mon, Oct 11, 2010 at 2:13 PM, Emil Dotchevski
<emil_at_[hidden]> wrote:
> 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.

If that is a template parameter that would work, but if not that adds overhead.

Personally, I still do not see what is wrong with having a default
function, so if boost::function is default constructed or ever set to
null then it is set to this default function instead (which by default
might throw?  But could be overridden on a per object bases, such as
when you just want it to do nothing if it is not set or so, I see
plenty of use cases and it satisfies all that is wanted and it removes
the if(function_pointer == null) check.