Boost logo

Boost :

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2011-11-24 12:56:22


Dean Michael Berris wrote:
> Or better yet, works now:
>
> namespace foo {
> void non_local_function(int i, bool b, long l, std::string const & s)
> {
> // do what I want here.
> }
>
> void f(std::vector<double> const &v) {
> int i;
> bool b;
> long l;
> for_each(begin(v), end(v), bind(&non_local_function, i, b, l, _1));
> }
> }
>
> See, no voodoo required here.

To be honest, this one really looks nice and convincing. I find it even looks nicer than the C++11 Lambda. And as you wrote in response to Lorenzo:

> But I did show a solution that works in both C++03 and C++11 which is
> to use bind to do it and a non-local function. Phoenix already enables
> doing magical things for in-line lambda's.
>
> Actually in all honesty, for any function that's going to be more than
> a couple of instructions long, as far as good engineering practice is
> concerned (and of course YMMV) you're going to want to make it an
> external function anyway so that:
>
> 1. You can test it.
> 2. You can make it externally linked.
> 3. You can use it again somewhere else (for free, you don't really
> have to if you don't want to).

I guess the compile and runtime performance will also not be worse than Boost.Local or Boost.Phoenix. (I just looked at the comparison chart in the documentation of Boost.Local, but it doesn't seem to include this version.)

You know what, I'm really happy now that I didn't participate in the review of Boost.Local! I'm no longer sure now whether it adds significant value or not. I have seen enough places where Boost.ScopeExit was the right solution, but these were one liners.

> > Of course, if you don't need to capture any variable from the
> > enclosing function, using Boost.Local will only make your code
> > more ugly.
>
> I agree.
>
> Now, do I still miss anything?

No, you got everything correct now.

Regards,
Thomas


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk