Re: [boost] New libraries implementing C++11 features in C++03

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-11-24 15:58:42

On Thu, Nov 24, 2011 at 8:40 AM, Dean Michael Berris <mikhailberis_at_[hidden]
> wrote:

> On Fri, Nov 25, 2011 at 3:23 AM, Thomas Klimpel
> <Thomas.Klimpel_at_[hidden]> wrote:
> > Dean Michael Berris wrote:
> >>>> There's *exactly* the same number of lines in a local function as
> >>>> there is with a class/namespace function. What am I missing?
> >>>
> >>> I'm actually also asking myself what I'm missing. Everybody seems to
> >>> claim that a namespace function provides the same functionality as a
> >>> local function.
> >>
> >> [...]
> >> It's not that complicated.
> >>
> >> The first approach is the way we've been doing it with normal C++. It
> >> works. It's not broken.
> >>
> >> I don't see why we'd ever need Boost.Local at all.
> >
> > OK, now I understand what you are missing. An important part of the
> functionality of Boost.Local is to capture variables from the enclosing
> function. Some even argued that C++ will never have true local functions,
> because you still have to specify the names of the variables from the
> enclosing function that you want to capture.
> >
>
> int i;
> bool b;
> long l;
> auto local_function = [i, b, l](std::string const & s) {
>  // do what I want here.
> }
> // use local_function somewhere else
>
> Hmmm?
>
> 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.
>
> > 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?
>

Well, a templated non_local_function would be...annoying, at best.  In that
case, I'd expect the best thing is to transition to a function object:

struct non_local_function { void operator()(int i, bool b, long l,
std::string const & s) { /*...*/ } };

... bind(non_local_function, i, b, l, _1) ...

However, it is...let's say, sometimes convenient...to declare the bound
variables at the point of definition of non_local_function rather than at
the point of higher-order use.  And, if you prefer including bound
variables to non_local_function explicitly like that, then you would
probably be adding member variables and constructors (or...use brace
initialization?).  Local's macros wrap all this boilerplate up for you (for
better or for worse).

- Jeff