Boost logo

Boost :

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

> 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

> 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

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 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 

Boost list run by bdawes at, gregod at, cpdaniel at, john at