It must have been a while since you last checked. Many of the features listed here as banned because of lack of VisualStudio support have been available in gcc and clang for years.
Not everyone has the most recent versions of the compilers, either; my institution is still working on the upgrade path from Ubuntu 12.04 LTS to 14.04 LTS, so I had to get a modern gcc manually compiled to get proper C++11 support, because nothing in the 12.04 package manager had full support.
I would be curious about the rationale behind this. Move semantics are a clear win in many situations, and I don't see any obvious pitfalls associated with them. I am curious especially about mere std::move; I'm aware that using rvalue references directly can be a bit confusing initially, and it makes sense to reduce their use.
Last I heard the C++ style arbiters at Google (a handful of very-senior engineers who dictate how everyone else at the company should write code) felt that rvalue references were too hard to understand and would therefore lead to more problems than they solve.
Admittedly my knowledge is a couple years old, but the rule specified here of "you can only use them with explicit permission from the C++ style arbiters; maybe we'll reconsider later" seems consistent with that reasoning.
I'm glad I don't follow their rules anymore. rvalue references are incredibly useful in making ownership transfers explicit, and although they may sound confusing on first description, once you get the hang of it, they are easy to reason about.
The problem is you're demanding that the entire coding population of a large company "get the hang of it" or else be confused by their tools. That is a proposition with non-zero cost, so it needs to be weight against the derived benefit.
And IMHO for move semantics, that benefit is pretty low. The overwhelming number of allocation bugs with C++ code are treated very well by RAII already. Move semantics tend to be best used in library code that implements some kind of dynamic runtime. And let's be honest: that's stuff that (1) tends to be done by experts already and (2) has been done successfully and robustly for decades in C anyway. Larry and Guido didn't need move semantics...
> The problem is you're demanding that the entire coding population of a large company "get the hang of it" or else be confused by their tools.
The fact of life in C++ is that you have to grasp a number of not-entirely-intuitive concepts before you can be effective with it. Rvalue references are not particularly hard compared to many of the others. Consider how much time newbies spend wrapping their head around pointers -- something that experienced C++ programmers have absolutely no trouble with.
The only reason we're holding rvalue references to a higher standard than any other C++ feature is because they're new, which means that even people who have been coding in C++ for decades suddenly find that there is a language construct they don't immediately understand. Not having felt this way for a very long time, they conclude that this particular construct must be much more complicated than everything else, when in fact it's not.
> The overwhelming number of allocation bugs with C++ code are treated very well by RAII already.
Move semantics make it vastly easier to use RAII in the first place. Without them, RAII does not play nicely with transferring ownership over a call or a return. You can use reference-counted smart pointers, but they are slow (require atomic ops). You can try to emulate move semantics via documentation and conventions, but this is error-prone. Clean ownership transfers have always been a sore spot in C++ prior to rvalue references.
I don't know about you, but the introduction of move semantics into my style completely transformed my code for the better.
We don't allow the standard version yet partly for the reason explained downthread: it requires stl support to be very useful and not all the platforms we target are compatible yet.
Its more than that. You can't put move-only types into std:: containers if the target doesn't have a C++11 support. There are many other pitfalls like this that are hard to notice until you try it on a pre-C++11 target.
Support for move semantics in library containers is a better reason for disallowing it, I'm just pointing out that std::move (and std::forward) is the simplest part of the puzzle.
Stuff like this makes me really regret being a C++ developer. Companies and projects are adopting new features at a glacial pace and yet the programming world is still moving forward and it feels like despite the best efforts of the committee and the compiler teams C++ is doomed to continue being a 'legacy language' as companies either continue migrating to C# or sticking with C++98.
Instead of living with regret, why not ask yourself what kind of software you want to be writing and what kind of problems you want to be solving? Some software should be migrated to C# and Java. On the other hand, when it comes to runtime performance, memory footprint, and compiler and runtime availability, nothing matches (or even comes close yet) to C/C++.
Some of C and C++ advantages come from having 30 years of compiler optimizations, while compiler vendors stoped caring about implementations for other languages.
I am big on C++, but as a language geek, I am looking forward to .NET Native release, and see how far it can take C# in this language X vs language Y discussions.
All great languages, but try finding a D compiler for a Blackfin chip, or something similarly esoteric. C++ just goes more places where you would want it to go.
Some of C and C++ advantages come from having 30 years of compiler optimizations, while compiler vendors stoped caring about implementations for other languages.
Certainly - with a clean slate in 2014, you'd design something else - something that would make static analysis easier and static constraints possible. Basically, something like Rust. But C++11 is still pretty cool.
I am big on C++, but as a language geek, I am looking forward to .NET Native release, and see how far it can take C# in this language X vs language Y discussions.
I had no idea C# was 'going native'. I guess we've come full circle, what with this and news of Android L moving to ahead-of-time-compiled 'java'. Still, I have absolutely no interest in C#.
> All great languages, but try finding a D compiler for a Blackfin chip, or something similarly esoteric. C++ just goes more places where you would want it to go.
Historical accident of compiler market. Not directly related to the programming languages themselves.
> I had no idea C# was 'going native'.
C# is already native when you target Windows Phone 8. It is just going native on the remaining Microsoft platforms.
I would be so happy if that comittee started removing features instead of adding them. Guidelines like that are just a way of dealing with all the complexity they introduced to C++ over the years.
That would lead to total ignoring of new language revisions, as well as using old compilers, instead of gradually opening up to new features as the various constraints permit. This is not the answer.
Being a simpler and easier to write/read language is also a feature, and a lot of people find value in such qualities. That's why golang is becoming more and more popular.
The definitive introduction to C++11 is probably 'C++ Primer 5th edition'. It covers stuff other than the new features but everything is described as it should be done in C++11/14.
Thanks for the suggestion. I am not a C++ programmer[1], but I try to keep an open mind about other languages. I loved reading Design And Evolution of C++, Bjarne has a very nice writing style.
[1] Last year, I spent about a week doing maintenance on what you could call a legacy C++ application at customer site (I work as a sysadmin at a process engineering company). It was strangely fun (lucky for me, the application was quite well-written and I could easily find my way around the code).
