Re: [boost] [function] function wrapping with no exception safetyguarantee

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

On Tue, Oct 12, 2010 at 7:59 PM, Peter Dimov <pdimov_at_[hidden]> wrote:
> Daniel Walker wrote:
>
>> But the coupling with Boost.Exception is only there to implement the
>> strong
>> exception safety guarantee of operator().
>
> Your terminology is wrong. Both variants of operator() have the same
> exception safety; and even if they didn't, nobody uses "strong exception
> safety" to mean "throws an exception when such-and-so".

OK, I think there is a terminology problem here. I think we need to
make a distinction between an "exception safety precondition" and a
"call precondition" with respect to functions.

A call precondition is a condition that must be met in order to call a function.

An exception safety precondition is a condition that must be met in
order to ensure that after a function has been called, during its
execution, it conforms to an exception safety guarantee.

Part of the requirements of boost::function is to account for
differences between function pointers and function objects. A function
object has no call precondition; i.e. a call to operator() cause
operator() to execute. A function pointer does have a call
precondition; i.e. a call to a function pointer only executes a
function if the pointer is not null.

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().

So, boost::function's precondition corresponds to a call precondition
not an exception safety precondition. boost::function is always strong
exception safe; i.e. boost::function invocation has no exception
safety precondition.

There are then two ways of looking at unsafe_function. You can say
that it does not transfer the call precondition of function pointers
in an exception safe way. Or you can say that it transfers the call
precondition by making it an exception safety precondition, in which
case unsafe_function is actually strong exception safe given the call
precondition. So, using terminology that hopefully everyone can agree
to, we can say that boost::function has no exception safety
precondition (it is unconditionally strong exception safe), but with
unsafe_function, the call precondition is an exception safety
precondition.

>
> The issue is not coupling with Boost.Exception, the issue is that the user
> has to supply a definition of boost::throw_exception when exceptions are
> disabled. This was true before there were Boost.Exception.

Well, I mean currently boost::throw_exception is part of
Boost.Exception. So currently, from a user's perspective at least,
boost::function is coupled with Boost.Exception.

Daniel Walker