Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk