On Mon, Oct 11, 2010 at 1:38 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
On 11 October 2010 12:21, Emil Dotchevski <emil@revergestudios.com> 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