Boost logo

Boost :

Subject: Re: [boost] [function] function wrapping with no exception safetyguarantee
From: Emil Dotchevski (emil_at_[hidden])
Date: 2010-10-22 03:57:21

On Thu, Oct 21, 2010 at 5:32 PM, Daniel Walker
<daniel.j.walker_at_[hidden]> wrote:
> I think in the case of function wrappers it helps to make a
> distinction between what I call a "call precondition" and an
> "exception safety precondition." A call precondition is a condition
> that must be met in order to invoke a function. One example would be,
> as you put it, "there must be a function to invoke;" i.e. the wrapper
> has to be assigned a target. Here's another example: Imagine we had a
> remote function wrapper so that remote function calls could be used
> interchangeable with other wrapped functions. Then a call precondition
> of the remote function wrapper would be that the remote host is
> available.

Assuming the remote host could disappear at any moment, this is a bad
example of precondition because the caller can not guarantee that the
host will be there by the time the function executes and completes.
This works well for postcondition example: the postcondition would be
that if the function returns then the remote host was available and
performed the task successfully (otherwise you'd get an exception.)

> An exception safety precondition applies after a function has been
> called and is running. And I like your wording, it is "a condition
> that the caller must satisfy in order for the called function to
> behave as documented" with respect to exception safety.

If the caller violates a precondition, all bets are off not only wrt
exception safety (the plane may crash, the patient may overdose.)

> I think the reason the distinction is important is that function
> objects do not normally have call preconditions; i.e. the function is
> always there, and when operator() is invoked, control is passed to the
> function.

The function you point to may still have its own preconditions. It
isn't a good idea to pass control to a function, through a pointer or
otherwise, unless its preconditions are met.

> With boost::function, the call precondition is handled
> transparently with respect to strong exception safety such that
> calling a wrapped function is the same as calling the function
> directly: Either an exception will be thrown or the function will
> complete successfully

...unless the preconditions of the target function aren't met, in
which case the plane crashes, the patient is overdosed, AKA undefined

>> I hope this helps, at least by clarifying terminology.
> Yes, thanks, I think it does help. You're using the term
> "precondition" in a broad sense

He is using the term precondition as it is used by everyone. Your
terminology appears to be wrong: what you mean by preconditions and
exception safety doesn't seem to be what everyone means by those

Emil Dotchevski
Reverge Studios, Inc.

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