Re: [Boost-users] Why use 'functional composition' with boost::bind

Subject: Re: [Boost-users] Why use 'functional composition' with boost::bind
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2010-08-04 12:56:43

On 04/08/10 07:43, WB wrote:

> As you say, all this is very trivial, and was meant to understand
> why Karlsson is exactly doing this, i.e. replacing something like
> 2*_1 with std::multiplies<double>(),2,_1 (Its on page 256 in my
> copy in chapter Library 9: Bind) So, I was trying to see if the
> compiler transforms the latter into the former - which seemingly
> does not happen. (which leaves me a little nervous about what
> boost::bind will do to you in the end anyway)

You don't seem to understand what 2*_1 is. It's a lambda expression. It 
generates a function object that takes one argument and returns 2 times 
that argument. It's basically the same as bind(multiplies<double>(), 2, 
_1), except multiplies is lazy and is replaced by operator* for nicer 
syntax.

You also seem to be confusing Boost.Lambda, Boost.Bind, and the standard 
function object helpers.

> That is really strange? For me
> Case 3 runs in ~1.8...1.9s, case 1 and 2 in 0.81...0.84s
> (I compile with gcc -O3 -Wall -lstdc++, nothing special)
> This leaves me even more nervous.

I used g++ -O3 -fomit-frame-pointer -march=native
Ubuntu Linux, Intel Core 2 Duo.

> Moreover I have included case 0, where I perform no access to the
> vector<T>  at all and only loop over the sin(), cos(), and random() stuff.
> For me this case runs ~0.16...0.19s. I.e. it seems that the 'old-fashioned'
> C-things are definitely not the problem, at least with gcc.

Nothing prevents the compiler from evaluating your whole code at 
compile-time.
For that reason, they're not really good performance tests. Chances are, 
the difference comes from the fact that the compiler managed to do more 
at compile-time in one of the cases.