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

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
behavior.

>> 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
terms.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode