Boost logo

Boost :

Subject: Re: [boost] [function] function wrapping with no exception safetyguarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-10-13 16:35:13

On Wed, Oct 13, 2010 at 1:31 PM, Emil Dotchevski
<emil_at_[hidden]> wrote:
> On Wed, Oct 13, 2010 at 9:41 AM, Daniel Walker
> <daniel.j.walker_at_[hidden]> wrote:
>> In "promoting" function pointers to function objects, boost::function
>> must transfer the call precondition from function pointers. To do this
>> in an exception safe way, it must check whether the call precondition
>> is met, otherwise it cannot offer a strong exception safety guarantee
>> during the execution of boost::function::operator().
> What Peter said: your terminology is wrong.
> Operator() of boost::function has basic (not strong) exception safety
> guarantee and this is true regardless of whether it wraps a function
> pointer or another callable object.

If the call precondition is not met and boost::function::operator()
attempts to call the target function, then the program could crash.
Instead, under the current implementation, boost::function::operator()
checks the call precondition and either completes successfully or
throws an exception with the program state maintained, which conforms
to our running definition of a strong exception safety guarantee.

> Basic exception safety guarantee means that *if* an exception is
> emitted as a result of calling boost::function::operator(), the state
> of the program may be altered but no resources will leak. Whether or
> not an exception is emitted has nothing to do with exception safety.

boost::function::operator() offers a stronger guarantee than that: it
either completes successfully or emits an exception, leaving the
program state unaltered. Again, there is a nuance here in that the
exact behavior of a boost::function invocation depends on the target
function. So more formally, boost::function invocation is strong
exception safe if the target function invocation is strong exception

Daniel Walker

Boost list run by bdawes at, gregod at, cpdaniel at, john at