Re: [boost] [function] function wrapping with no exceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping with no exceptionsafetyguarantee
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2010-10-11 10:43:34

"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)...

> 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