Re: [boost] [function] function wrapping with no exceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping with no exceptionsafetyguarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-10-11 14:42:59

On Mon, Oct 11, 2010 at 1:38 PM, Nevin Liber <nevin_at_[hidden]> wrote:
> On 11 October 2010 12:21, Emil Dotchevski <emil_at_[hidden]> wrote:
>
>> If you don't disable exception handling, the compiler must treat the
>> dynamic call in boost::function as potentially throwing. There is no
>> way around that.
>>
>> (If you do disable exception handling, boost::function already does
>> not throw.
>
> Given all that, is there any more to this proposal than to take the
> previously well defined behavior of calling an "empty" function and
> making it undefined behavior (and not for the purpose of
> optimization)?

Correct. unsafe_function is the same as boost::function except that
its behavior is undefined when it has no target. In this way, it
behaves more like a function pointer than boost::function, which is
desirable for projects that do not use RTTI (and don't want to bother
configuring Boost.Exception, which is understandable). unsafe_function
works out-of-the-box in RTTI-free environments; boost::function does
not due to its strong exception safety guarantee.

> Since "undefined behavior" pretty much means we can do
> whatever we want, don't we already meet that definition?

By "undefined behavior" I mean we do not define the behavior in the
event that the pre-conditions of operator() are not met. And indeed,
we cannot define the behavior in any platform independent way, because
it involves dereferencing a null pointer.

Daniel Walker