|
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
> } BOOST_LOCAL_FUNCTION_END(localf)
>
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?
Cheers
-- Dean Michael Berris http://goo.gl/CKCJX
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk