Boost logo

Boost :

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-11-25 05:44:41

On Fri, Nov 25, 2011 at 9:20 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
> On Thu, Nov 24, 2011 at 9:53 PM, Dean Michael Berris
> <mikhailberis_at_[hidden]> wrote:
>> Not just that. It's also because it's trying to approximate something
>> limited as compared to what C++11 already has.
> a) OK, I think I understand. My reply if that if Boost.Local does not
> approximate well C++11 lambdas because it cannot be define within
> expressions, it instead approximates well named lambdas which are
> closures defined at declaration scope:
> int a;
> auto localf = [&a](int z) {
>    ... // lots of instructions here
> };
> This C++11 construct is well approximated by the following in C++03:
> int a;
> void BOOST_LOCAL_FUNCTION(int z, bind& a) {
>    ... // lots of instructions here

Sorry, I don't think you *do* get it.

Named lambda functions are an oxymoron. When you give a name to a
function, it ceases to be a nameless function. The *utility* of having
a function defined inside another function is marginal at best because
they're absolutely better outside any other functions in all aspects:
readability, maintainability, and functionality.

There's *no* practical reason to put a lambda in a named variable when
the point of lambda's are so that you can define them in-line. I would
even say that it's bad practice to do this at all in C++11 code for a
lot of reasons:

  auto f = [](...) { /* whatever */ };

Some of the reasons are:

1) This messes up ADL and would lead to hard-to-find bugs.

2) You're cluttering the function definition with logic that's
supposed to not even be in the same function.

3) It's not a real function that can be referred to via function pointers.

Is that clear enough for you?

> b) Other libraries like the recently reviewed Boost.Algorithm and
> Boost.Atomic implement C++11 features for C++03. I would expect the
> ability of Boost.Local to implement C++11 named lambdas (i.e., local
> functions) for C++03 to be just as valuable. Why wouldn't it?

There's a difference between a back-port like in the case of
Boost.Algorithm, Boost.Atomic, and Boost.Unique_ptr, drop-in
(forwardable) approximations like Boost.Move, and a very narrow and
marginally useful approximation like what Boost.Local provides. Does
that make it clearer?


Dean Michael Berris

Boost list run by bdawes at, gregod at, cpdaniel at, john at