On Mon, Oct 11, 2010 at 2:13 PM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Mon, Oct 11, 2010 at 12:57 PM, Daniel Walker <daniel.j.walker@gmail.com> wrote:
On Mon, Oct 11, 2010 at 3:20 PM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Mon, Oct 11, 2010 at 11:53 AM, Daniel Walker <daniel.j.walker@gmail.com> wrote:
On Mon, Oct 11, 2010 at 2:45 PM, Daniel Walker <daniel.j.walker@gmail.com> wrote:
On Mon, Oct 11, 2010 at 2:05 PM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Mon, Oct 11, 2010 at 10:45 AM, Daniel Walker <daniel.j.walker@gmail.com> wrote: > On Mon, Oct 11, 2010 at 2:49 AM, Nevin Liber <nevin@eviloverlord.com> wrote: >> On 11 October 2010 00:01, Emil Dotchevski <emil@revergestudios.com> wrote: >>> On Sat, Oct 9, 2010 at 12:38 PM, Daniel Walker >>> <daniel.j.walker@gmail.com> wrote: >>>> Finally, there have been suggestions to alter boost::function's >>>> exception safety guarantee directly through either policies or >>>> constructor options. >>> >>> We used to have an Allocator parameter to the boost::function template >>> and it was removed (just in time for this change to also be reflected >>> in C++0x) to reduce coupling. >> >> So what exactly is the proposed behavior if the function object cannot >> fit in the small object optimization space of unsafe_function and the >> allocation fails? > > As proposed, unsafe_function has the same semantics as boost::function > with one (and only one) exception: the behavior of operator() is > undefined when it has no target.
If that was the only motivation, you could just disable exception handling, and then define:
namespace boost { void throw_exception( std::exception const & ) { assert(0); } }
Correct. But users have complained about this, which is exactly the motivation for unsafe_function. It works out-of-the-box in RTTI-free environments with no dependency on boost::throw_exception. It's a simple problem really.
P.S. Sorry I spoke to soon. That's not exactly correct. A user could do what you describe, but boost::function could not, since that would change its exception safety guarantee; i.e. it would no longer throw (or call a user definable function) when it had no target.
This is not exception safety issue, it is a choice between defined and undefined behavior.
A strong exception safety guarantee is a defined behavior.
Any behavior fits "undefined behavior". Like I said, if someone wants undefined behavior, they can't be against any particular behavior, including throwing an exception.
Another group of users, would like a function wrapper without coupling Boost.Exception, and indeed, without an exception safety guarantee. unsafe_function address the demands of this second group of users.
What is the problem with adding a constructor such that you could say:
boost::function<T>(f,std::nothrow)
This way, I'm pretty sure that as long a program only instantiates the nothrow constructors, the resulting executable won't depend on boost::throw_exception.
If that is a template parameter that would work, but if not that adds overhead. Personally, I still do not see what is wrong with having a default function, so if boost::function is default constructed or ever set to null then it is set to this default function instead (which by default might throw? But could be overridden on a per object bases, such as when you just want it to do nothing if it is not set or so, I see plenty of use cases and it satisfies all that is wanted and it removes the if(function_pointer == null) check.