"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)...
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 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 Your modification only eliminates the if-not-then branching overhead which, yes, can be almost completely removed by a powerful enough optimizer in some circumstances, e.g. if operator() is inlined and the function object is repeatedly called in a simple loop as is the case in a typical and simple synthetic benchmark... However this still does nothing concerning the exceptions vs no-exceptions comparison/debate because the compiler still has to treat function<>::operator() as a possibly throwing function (and add/generate appropriate EH code in/for the callers) because it makes an indirect call through a (undecorated) pointer... 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... Note that not all compilers implement exception handling with the theoretical 'bloat-but-no-time' overhead...among those is also MSVC++ (all versions) when targeting 32 bit x86 (which is still the dominant compiler-platform combination) which also introduces a run-time overhead and the presence of EH states in a function seriously hinders its optimizer for some typical tasks (such as inlining and NVRO)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman