At Mon, 11 Oct 2010 14:19:31 -0400, Daniel Walker wrote:
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.
I'm sorry if I missed something important here, but has everybody really considered the consequences of Peter Dimov's post, where he wrote:
This example implies that unsafe_function is inherently more efficient, but this need not be so. An empty function may point to throw_bad_function_call instead of NULL.
One could swap out throw_bad_function_call for any behavior you like.
<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.
If that's *really* its goal, unsafe_function is strictly unneeded. boost::function already satisfies all your requirements (and more). I think if you're looking to supply motivation for unsafe_function, you'll need to describe the goal differently. ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com