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:45:55


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.

Daniel Walker


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