Re^5: Real life uses for closures. (update: disambiguation)

[davido]

Apparently they're seen as useful enough that C++11 got them, in its own C++ish way. You're probably already familiar with this new addition to C++, but just in case, C++ lambda functions can capture the state of their enclosing scope. The consensus seems to be that adding this feature to C++ was a big win for the language... something Perl's been doing for decades.

An introductory article on C++11's lambda closures.

One difficulty that C++'s "closures" have is that you can't really share a variable from an enclosing scope across several lambda functions if the variable's outer scope ends. This is because the way C++ implements them, the captured variables are either copies, or references. Copies can't really be shared. References can, but if the target falls out of scope the lambdas are left holding the bitter end of an unfastened rope.

But all is not lost; C++11 got shared reference counted pointers too.

[BrowserUk]

Yes. I watched (the video of) Stroustrup's keynote There are some very interesting features in it; and some disappointments over what didn't get in.

The only problem is it'll probably be 2015 at least before the major compilers fully support the standard; and around 2025 before major projects will consider it safe to use any of the new features. :(

I mean C99 introduced inline functions which are a far better choice for most things that use those horrible multi-line extended macros that litter most OSS libraries and projects, but still you find those 30 line #define macros everywhere because -- apparent -- there may be some user in Outer Mongolia that still hasn't got a C99 compiler.

[davido]

In the case of C++11, the major compilers already support most of it. g++ is lacking on its regular expression support, and MSVC++ was a little slow with variadic templates, but I think they're implemented now. Most of what is most important is there; move semantics, rvalue references, ranged loops, auto and decltype, modified return value function syntax, reference counted pointers, lambdas, and so on.

But your second point is right on the mark; though everyone's excited to use these new features, often the new features are avoided in the name of backward compatibility, and I haven't a good feel for C++11 features being accepted into newer projects.

I can say that the standard library has been rewritten in most major implementations to take advantage of move semantics, which is a really big win that nobody really sees -- like trie optimization in Perl's regexes, it's just there behind the scenes.

Anyway.... I've taken us way off topic. I apologize for rambling in your thread. :)

[BrowserUk]

Anyway.... I've taken us way off topic. I apologize for rambling in your thread. :)

Actually, you haven't. The underlying motivation behind my asking the OP question was itself pretty off-topic -- though underlying that is very Perl-related -- and it is my belief that a truly modern (rather than a labeled-modern dialect), computer language like C++11 (or D2 or few others), is the future of Perl.

That is to say, I think that everything that is wrong with Perl5; and all the things that have gone wrong with the previous and ongoing attempts to implement Perl6; are firmly routed in the archaic programming languages and practices that have been and continue to be used to implement their infrastructure:

• Using macros to force inlining -- whether beneficial or not -- instead of inline functions.
• malloc & free rather than RAII;
• The pile'em high, wherever-it-fits heap-based memory use.
• Pointers instead of references;
• Consting & copying rather than move semantics in an attempt to solve the shared state problem.
• Emulating a register-rich cpu in software, atop inherently register-poor, stack-based hardware.
• Non-reentrant libraries, non-PIC, and god-object context encapsulation.
• Code that leaves the requirements of multi-threading to be retrofitted as an afterthought.

Until and unless truly modern coding practices are used to (re-)construct the infrastructure required to support dynamic languages -- Perl et.al. -- they will surely become less and less relevant in a modern world.

So far from off-topic rambling, your bringing up C++11 was right on-topic for the thought processes that led to this thread. Thank you.