Re: [boost] [function] function wrapping with noexceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping with noexceptionsafetyguarantee
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-11-02 15:17:58

On Tue, Nov 2, 2010 at 1:17 AM, Emil Dotchevski <emil_at_[hidden]> wrote:
> On Mon, Nov 1, 2010 at 8:58 PM, OvermindDL1 <overminddl1_at_[hidden]> wrote:
>> Â f(unsafe_no_throw,1); // possible new syntax, calls function, no null check
>> Â u(unsafe_no_throw,1); // possible new syntax, whatever the platform
>
> This is somewhat redundant since you can already do
>
> assert(f);
> f(1);
>
> I was proposing a similar change, to add a boost::function constructor
> that takes std::nothrow_t, which can be used to initialize an empty
> function object which asserts and doesn't throw upon calling op().
> However I'm not sure there is a use case even for this: it lets you
> pick throw or no-throw semantics, but no-throw semantics are only
> useful in BOOST_NO_EXCEPTIONS builds, and therefore the global
> no-throw behavior supported by boost::throw_exception should be
> sufficient.

With a smart enough optimizer, that should indeed remove the `if`
check (my purpose of this), but that then adds an assert in the code
that will still get run at runtime.  The problem with adding a
nothrow_t in the constructor is that state then needs to be held (or
you need to templately-branch based on it, which would remove the
runtime state requirement, but that is a lot of extra code to manage),
but there are some places in code where calling a boost::function may
very well possibly be null, and an exception may be warranted (like
outside of my code), but other places (like inside of my code) I
already know before-hand whether or not a function is null or not and
whether or not to call it, even if I have no `if` check before its
call, just based on how the program flow works.  I just want it to
call it, potentially inline it (which I have seen the optimizer do
nicely enough), with no dang checks getting in the way.  The called
function might still throw, might not, who knows, I just do not want
the check, and yes I have a use-case for it in tight loops (where
currently a fastdelegate outperforms the identical code using
boost::function by a rather healthy margin, and looking at the
assembly, the only difference is the `if` check).