So the lambda functions are implemented in a way that only really works with templates and you have to explicitly pass scope? I don't really write C++ "natively," but this seems awkward to me, particularly vis-a-vis Apple's implementation of blocks in C. Does it look better to anyone who has a better handle on the feel of idiomatic C++?
I've been using them for a while now (gcc has support) and they're not awkward. The ability to specify scope is actually rather nice and most of the time you'll either leave the scope empty with [] or pass everything in by value [=] or reference [&]. The return type of the lambda function is also usually detectable by the compiler so you only need to specify it rarely.
To be more specific: the return type of the lambda can be omitted for a lambda whose body is just "return {expression}". The compiler could, if it wanted, always deduce the return type (since implementing type inference would be easy). The fact that it doesn't isn't to make it easy for compilers; it was a design decision of the language: having unspecified return types for complicated pieces of code hurts readability and maintainability.
Return types can't always be deduced since they can be ambiguous - imagine an if statement where one branch returns a float and the other returns a double. The desired return type could really be any numeric value since the types can be converted so the return type does need to be specified. Since C++ has overloaded functions the compiler can't just look at the function that the result is being passed into to determine the type either.
The solution would be then to do autoconversions as appropriate or return an error.
The compiler already deals with this issue with the ?: operator. It's a readability and maintenance problem there, too. It'd be easy to do; the language designers chose not to.
Requiring the use of templates (or std::function) is how closures work in C++ already. The new lambda syntax is just a (much) easier way to create closures, so it suffers from some of the same problems. I've never found wrapping things in std::function to be much of a problem, though.
You can "explicitly" pass all variables in the containing scope with [=] or [&], so it's more of an optional annotation than a requirement.
I guess by making the closure explicit they've made implementing them much easier too. The problem of trying to figure out which variables the function is closed over is no longer there (which makes me curious because judging from my own experience in creating a scheme-clone, this wasn't that difficult). I bet it just transforms down into a function or maybe even gets inlined.
There's no such thing as idiomatic C++. The language is so huge and complex that all successful teams I've worked with that use it have selected a subset to use as part of their coding standard. In each case those subsets were different
Most languages have a spectrum of skill, and it generally is possible to progress upwards in skill for any given language as long as you have mastered the basics. C++ is different. Because C++ is very much: "here's some tools to write your own C-like language, go nuts!" Idiomatic C++ is so widely variant it rightly justifies as being different languages. The extreme end of the spectrum of C++ usage (and I speak not of niche usage but day-in-day-out being-used-at-huge-companies usage) is as different from "ordinary" idiomatic C++ as Python or Ruby might be.
I thought the same thing when I starting working with the new standard, but I've really grown to enjoy a lot of the new features, specifically the new pointer types, rvalue references, initializer lists, variadic templates, and better support for functional programming via binds and lambdas. C++0x really does fix a lot of things that were broken on awkward previously, while also expanding support for memory and speed constrained systems via things like std::array. For me, this stuff breaths new life into the language.
I may be in the minority, but I like header files. Interface => Implementation, enforced at the file level. Add Obj-C's #import macro and they even look reasonable!
Well, you either have to publish your member variables and their names to the world, or use PIMPL, which is (I think) a bit of a hack. Having partial classes (a la C#) would be nice for this.
http://en.wikipedia.org/wiki/C1X is the new 'C' draft standard, I think that the C++ guys figured they'd be ready a bit earlier than this. They might name it C++09 to save face.
26 comments
[ 3.1 ms ] story [ 78.8 ms ] threadThe compiler already deals with this issue with the ?: operator. It's a readability and maintenance problem there, too. It'd be easy to do; the language designers chose not to.
You can "explicitly" pass all variables in the containing scope with [=] or [&], so it's more of an optional annotation than a requirement.
Most languages have a spectrum of skill, and it generally is possible to progress upwards in skill for any given language as long as you have mastered the basics. C++ is different. Because C++ is very much: "here's some tools to write your own C-like language, go nuts!" Idiomatic C++ is so widely variant it rightly justifies as being different languages. The extreme end of the spectrum of C++ usage (and I speak not of niche usage but day-in-day-out being-used-at-huge-companies usage) is as different from "ordinary" idiomatic C++ as Python or Ruby might be.
P.S. I've working with C++ for more than 10 years.
leaving it up to the programmer is a waste of time.