Re: [boost] [function] new implementation

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 
news:01d101cb79de$43ce5f50$cb6b1df0$@gmail.com...
> 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 
it...
If you do not rely on the throw-on-empty behaviour you can use a different 
on-empty-handler.
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 
defaulted...

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

> 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