On 13 October 2010 15:35, Daniel Walker <daniel.j.walker@gmail.com> 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@eviloverlord.com> (847) 691-1404