Boost logo

Boost :

Subject: Re: [boost] [function] new implementation
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-11-01 17:53:40

"Hartmut Kaiser" <hartmut.kaiser_at_[hidden]> wrote in message
> Yep, that fixes the assertion. Thanks a lot. I'll do some performance
> comparisons later.

If you want, you can also play with some of the new features.
I already mentioned the 'compile-time' assign() overloads (not really
necessary for a 0x lambda enabled compiler like VC10).
If you do not need the runtime type introspection functionality, try
BOOST_FUNCTION_NO_RTTI (for me, in a project with lots of
meta-template-programming generated targets, this resulted in the largest
binary size reduction)...of course, be careful about the ODR if you use
If you do not rely on the throw-on-empty behaviour you can use a different
For boost::functions<> to which you only assign targets that you know are
nothrow you can also set the is_no_throw policy to true (in x64 mode for
MSVC this only has possible binary size reduction benefits, unlike in x86
mode where it also has possible runtime speed benefits)...

You use policies like this:

  typedef boost::mpl::map2
      boost::mpl::pair<boost::empty_handler_t, boost::assert_on_empty>,
      boost::mpl::pair<boost::is_no_throw_t , boost::mpl::true_ >
> my_bf_policies;

  boost::function<int(int), my_bf_policies> my_bf;

You don't need to specify all policies, the one(s) you do not mention are

ps. I developed a kind of 'release-mode link-time'
'is-it-really-a-nothrow-function' system that will reject (invoking the
empty-handler) at runtime any target not detected as nothrow that was tried
to be assigned to a b.function marked as nothrow...(it will obviously reject
all function pointer targets as such 'optimizer introspection' does not work
with indirect calls)...This was tested to work in 32 bit release mode with
MSVC (8, 9 and 10)...unfortunately it does not seem to work in x64 mode (it
seems there was a serious regression in the MSVC optimizer in that mode)...
Anyways I've just changed this so that this check is skipped (and the assign
automatically/always performed) for all unsupported/untested platforms
(making it the user's responsibility to make sure what targets it tries to

> The assertion fired during the construction of the first non-empty
> function
> object. So it should be easy to reproduce.

I could not reproduce this...considering it is/was a function alignment
issue I'd say the crucial part is the type of target you tried to assign
(because the generated 'back-side' code directly depends on this)...

"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