On Thu, Oct 21, 2010 at 5:32 PM, Daniel Walker <daniel.j.walker@gmail.com> 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