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:19:31

On Mon, Oct 11, 2010 at 10:43 AM, Domagoj Saric
<domagoj.saric_at_[hidden]> wrote:
>
> "Daniel Walker" <daniel.j.walker_at_[hidden]> wrote in message
> news:AANLkTikdt4Cx9QcqeUX=SZ9rB8uqrmaahLpfMgxtEkTv_at_mail.gmail.com...
>
>> I have to say that I don't find the idea of gutting the current
>> implementation to be particularly attractive. Boost.Function is
>> already proven and familiar, and there's more we can still do with it.
>
> We can do more with it w/o 'gutting' it? I'm sorry I do not understand why
> unsafe_function does not constitute 'gutting' while my changes do...note
> that 'my' function requires no macro or a different name and is backwards
> compatible with existing code (it only needs to be recompiled)...

My patch is very simple, and there are very few changes to the
existing code. It uses the existing preprocessor metaprogramming
infrastructure of Boost.Function to generate the same implementation
code for both boost::function and unsafe_function with one small
exception: The guarantee that operator() throws when it has no target
is removed from unsafe_function. So, the vast majority of the
implementation (type-erasure management, etc.) is unchanged.

>
>
>> Plus, it takes time to study a lot of new code.
>
> Ideally this should not be an argument as it takes time to do anything
> (right)...

I only offer that statement as an explanation for why rewrites of
familiar projects are often not embraced. It takes time for people to
study the new implementation. If the current implementation is already
trusted, then there is less incentive to invest time in studying a new
implementation.

>
>> I don't believe efficiency is a significant issue. I tried to measure
>> the difference in performance between boost::function and
>> unsafe_function in a tight loop, and with gcc -02, the difference is
>> on the order of hundreds of picoseconds; i.e. in optimized code on
>> contemporary PC hardware, unsafe_function is not significantly more
>> efficient. But of course, results will vary according to your
>> optimizer.
>
> Just to clear something first, it seems to me you misunderstood the meaning
> of the exception safety guarantee which AFAICT has nothing to do with your
> proposal:
> http://en.wikipedia.org/wiki/Exception_guarantees

unsafe_function offers no exception guarantee. In the wiki's
terminology, it would be called "exception unsafe." Hence the name.

> <snip>
> However, here http://lists.boost.org/Archives/boost/2010/01/160908.php you
> can see results that show a measurable difference when function<> is
> configured to mark itself as nothrow...

The goal of unsafe_function is not to provide a wrapper that doesn't
throw, but to provide a wrapper with no exception safety guarantee.

Daniel Walker