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

Subject: Re: [boost] [function] function wrapping with no exception safetyguarantee
From: Nevin Liber (nevin_at_[hidden])
Date: 2010-10-13 17:57:18

On 13 October 2010 15:35, Daniel Walker <daniel.j.walker_at_[hidden]> wrote:
> If the call precondition is not met and boost::function::operator()
> attempts to call the target function, then the program could crash.

In the case of raw function pointers (either NULL or uninitialized),
from that point on the program can do whatever the heck it wants to
do, since it is now in the realm of undefined behavior.  Heck, you can
no longer guarantee that *any* object in your system is still in a
consistent, let alone correct state.

> Instead, under the current implementation, boost::function::operator()
> checks the call precondition

What call precondition?  It is perfectly legitimate to call operator()
on a default constructed boost::function; it has well defined
semantics.

Now in your new class you want to change those well defined semantics
into undefined behavior.  But "undefined behavior" means that the
program can do whatever the heck it wants, including the currently
defined behavior for calling operator() on a default constructed
boost::function.

For a parallel, look at std::vector at() vs. operator[].  at() has no
precondition on the index passed to it, while operator[] requires it
to be in the range [0..size()).

Would you say that operator[] doesn't have the strong exception safety
guarantee?

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

Exception safety is an orthogonal issue, as you are talking about
changing well defined semantics into undefined behavior.  Undefined
behavior in and of itself just isn't a motivation for any feature.
And you aren't (just) relaxing the exception safety guarantees;
rather, you are throwing them (as well as any other guarantees) out by
invoking undefined behavior.
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]