On Mon, Oct 11, 2010 at 10:43 AM, Domagoj Saric <domagoj.saric@littleendian.com> wrote:
"Daniel Walker" <daniel.j.walker@gmail.com> wrote in message news:AANLkTikdt4Cx9QcqeUX=SZ9rB8uqrmaahLpfMgxtEkTv@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