10 ms·

Rundown of the newest features in C++11 [pdf]

67 points by octo_t 13y ago

Game_Ender 13y ago
I have read quite a few overviews, and I really like the direct C++03 vs C++11 code comparisons in this one. It's get right to the point of showing the things that C++11 is trying to fix.
shared4you 13y ago
The last slide: gcc (38/39) -- Not implemented: threads, regex I think this is no longer true. I've some threads and regex code running well with gcc 4.7 and 4.8. Anyone knows when was this presentation given? It doesn't have any date.
- frontfor 13y ago
  According to the metadata contained in the PDF file the creation date of this file is 9 January 2013.
- plorkyeran 13y ago
  4.7's thread implementation is missing sleep_for, and possibly some other stuff. <regex> is still mostly not implemented in 4.8.
- vinkelhake 13y ago
  libstdc++ is still missing C++11-features. Regex and thread are still not complete: http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#s...
AldousHaxley 13y ago
This is really helpful. I'm kind of thrown by the page about "final". The C++ example shows a method that is both virtual and final, which seem to be in contradiction of each other. Or am I missing something?
- Someone 13y ago
  It is the effect of making the example as short as possible. The price one pays is that it becomes pointless/silly (http://stackoverflow.com/questions/11704406/whats-the-point-of-a-final-virtual-function http://stackoverflow.com/questions/11704406/whats-the-point-...). In C++, the keyword 'virtual' can be used to introduce a new virtual member function and to re-assert that a member function is virtual (http://stackoverflow.com/questions/4895294/c-virtual-keyword-for-functions-in-derived-classes-is-it-necessary http://stackoverflow.com/questions/4895294/c-virtual-keyword...). Using 'final virtual' only makes sense for the second use, but is legal in the first context because of the re-use of the 'virtual' keyword.
- plorkyeran 13y ago
  Nonvirtual functions are effectively always final; if you have a pointer to a Foo which has a nonvirtual member function Bar, then you will always call Foo::Bar even if the thing being pointed to is actually an instance of a subclass that defines its own Bar member function. Using final without a base class only makes sense if you don't actually want virtual semantics but specifically need the function to be in the vtable for some reason (such as for COM).
- IvoDankolov 13y ago
  Yes, you are missing something, which is a bit of a quirk of C++. Normally, having two functions with the same signature in a parent and child class results in overloading. struct A { void f() {std::cout << "A";} }; struct B : A { void f() {std::cout << "B";} }; //.,... A a = B(); B b = B(); a.f(); b.f(); b.A::f(); This would print ABA, as the child's f() function simply hides the parent one when working in the context of B(), but it does not override it. Now, what virtual does is it tells the compiler, "from here on out, resolve clashing signatures for this function in child classes by overriding. I'm sure you know how our example changes when you mark f() as virtual. That's all old news, though. The more interesting bit, final, acts like so: from here on out, prevent overloading in child classes. Now, that only makes sense in the context of virtual, so that's the only place where you're allowed to use final, and here the actual difference to the first example becomes apparent. You see, final does not negate virtual, what it actually does is completely lock up the function signature from being used in any child classes. Adding virtual final to our example would not cause B's function to hide A's - it will simply not compile. If you think that's all pointless semantics, you are absolutely right. Locking up names is not the point of "final". In fact, declaring something as virtual final in the base class is completely pointless from any practical standpoint. The actual problem that final is meant to solve is this: As I mentioned earlier, virtual changes the way resolving names works in child classes forever. These two pieces of code are absolutely equivalent. struct A { virtual void f() {std::cout << "A";} }; struct B : A { void f() {std::cout << "B";} }; And: struct A { virtual void f() {std::cout << "A";} }; struct B : A { virtual void f() {std::cout << "B";} }; Therein lies an interesting dilemma. What if I wanted to prevent any child class of B, and only B, from changing the implementation of f. Under C++03, that is not possible. In C++11, final solves that. But why go through the trouble of introducing a new keyword - and a keyword that is only a keyword in class and function declarations to boot (Holy context dependent grammar, Batman!) - and not just drop the virtual qualifier? Backwards compatibility - ever a dreaded thing when you wish you could undo your old mistakes. It isn't all that big of a deal (said the C++ developer about every strange rule in the language, ever), though, since when you use "final" for the intended purpose, you won't actually be needing the virtual qualifier. struct A { virtual void f() {std::cout << "A";} }; struct B : A { void f() final {std::cout << "B";} }; struct C : B { void f(); //I'm afraid I can't let you do that. };
general_failure 13y ago
Great slides. This is the first time I am seeing a direct C++03 and C++11 comparison. Makes it much easier to understand. That said, c++11 is a language that wants to be everything. Functional, object oriented, procedural, imperative, declarative and what not. The end result is slush.
- eksith 13y ago
  Slush is possible in C++03 as well. I'd say C++11 is trying to be humane as possible in that regard and not destroy the program (or the output) on account of programmer idiosyncrasies, no? What I would much rather prefer is a "from scratch" approach to learning C++11 (assuming no prior knowledge about programming, but having a basic knowledge about memory etc...) That would really help curb the tide of novice programmers seduced by sexier languages that have no concept of safety, efficiency and correctness.
  - asdfgP 13y ago
    A good introductionary book about C++11 is "C++ Primer": http://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/0321714113 http://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/032171... What I like about this book is that it teaches you the new C++ way right from the beginning. Rather than walking you through the history of C, it gets you to the modern practices immediately. Disclaimer: I have only read the first 10% of the book myself, but so far I like it.
- stephen_g 13y ago
  Slush? Depends how you use it. It's extremely easy to write horrible C++ code, but when used by a talented developer I think the result can be extremely elegant. I like how it's a lot more expressive than C, but without the needless verbosity of a language like Java.
  - betterunix 13y ago
    C++ still has quite a bit of needless verbosity. You need to explicitly specify how variables should be captured in lexical closures. You need to explicitly choose weak pointers versus non-weak pointers. There are few useful defaults; you are forced to explicitly write a lot of boilerplate as a result. It may be better than Java, but that is not saying much.
JoshTriplett 13y ago
Personally, I'd like to see some of these features added to C where they make sense. Raw strings, bind, lambdas, constexpr, and ranged for loops would all make sense in C.
- gcr 13y ago
  How could lambdas make sense in C? Keeping closures around means having to keep free variables around. C doesn't have garbage collection, so it would be quite awkward to establish conventions about who gets to free the variables that each closure references.
  - betterunix 13y ago
    How does any of that not apply to C++?
    - deleted 13y ago
      [deleted]
    - kybernetyk 13y ago
      Closures work pretty great with std::shared_ptr.
      - betterunix 13y ago
        Unless you have a cycle.
  - JoshTriplett 13y ago
    Take a look at the "blocks" extension to C, in LLVM. It includes mechanisms to handle the lifetime issues, though it does still require explicit memory reclamation of blocks.
- iambvk 13y ago
  I agree! I found no libraries that give std::bind functionality in C and GCC extensions also doesn't offer any solutions.
dakimov 13y ago
Very concise. Great!
kubov 13y ago
Even with those enhancements, C++ remains incredibly complex language, with such a great variety of features the learning curve would be rising very slowly over time.
- tspiteri 13y ago
  with such a great variety of features the learning curve would be rising very slowly over time. That is not necessarily true. The point behind C++11 is to provide new features that are easier to learn than the features they replace. So C++11 on its own has a lower learning curve than C++03. Of course, if you're maintaining older code, then your point stands, and the learning curve would be rising because of the extra new features.
CamperBob2 13y ago
string test=R"(C:\A\B\C\D\file1.txt)"; Hmm, that's ugly. Why are those parens needed?
- vinkelhake 13y ago
  You can prefix the left parenthesis with a string. You then repeat that string after the right parenthesis. By doing this you can include sequences in the raw string literal that would have otherwise terminated it. R"foo(xyz)")foo";
- bskari 13y ago
  The parentheses are used as delimeters so that you can use quotes in the literal. string test = R"(the Star Trek catchphrase "Beam me up, Scotty" did not appear)"; If you want to use quotes in the string, you can add up to 16 chars to the delimiter, but you still have to use the parentheses. string test = R"[de=limiter!(the (Star Trek) catchphrase "Beam me up, Scotty" did not appear)[de=limiter!";
alisnic 13y ago
proposal: cpp.wikipedia.org - to categorize and store all the stuff cpp had and have. </sarcasm>
JulianMorrison 13y ago
I just have to thank my lucky stars i don't work with it. It's like they are trying to iterate a power saw into an aeroplane by gradually adding features while remaining backwards compatibility as a power saw. Please hurry up and finish Rust, is all I can say to that.
- Erwin 13y ago
  I think it's a great update. Everyone already using C++ on a platform that has the required tooling (also considering libraries, IDEs) will benefit from updating. Compare to that Python 2.x to Python 3.x. I have no interest in updating my XX kloc of Python code so that... unicode becomes cleaner?
thebear 13y ago
This is a great overview. However, in order to use the new C++11 features correctly and avoid pitfalls, one must dig a bit deeper. A good example is auto and decltype: http://thbecker.net/articles/auto_and_decltype/section_01.html http://thbecker.net/articles/auto_and_decltype/section_01.ht...

67 points by octo_t 13y ago

I have read quite a few overviews, and I really like the direct C++03 vs C++11 code comparisons in this one. It's get right to the point of showing the things that C++11 is trying to fix.

shared4you 13y ago

The last slide: gcc (38/39) -- Not implemented: threads, regex I think this is no longer true. I've some threads and regex code running well with gcc 4.7 and 4.8. Anyone knows when was this presentation given? It doesn't have any date.

frontfor 13y ago
According to the metadata contained in the PDF file the creation date of this file is 9 January 2013.
plorkyeran 13y ago
4.7's thread implementation is missing sleep_for, and possibly some other stuff. <regex> is still mostly not implemented in 4.8.
vinkelhake 13y ago
libstdc++ is still missing C++11-features. Regex and thread are still not complete: http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#s...

AldousHaxley 13y ago

This is really helpful. I'm kind of thrown by the page about "final". The C++ example shows a method that is both virtual and final, which seem to be in contradiction of each other. Or am I missing something?

Someone 13y ago
It is the effect of making the example as short as possible. The price one pays is that it becomes pointless/silly (http://stackoverflow.com/questions/11704406/whats-the-point-of-a-final-virtual-function http://stackoverflow.com/questions/11704406/whats-the-point-...). In C++, the keyword 'virtual' can be used to introduce a new virtual member function and to re-assert that a member function is virtual (http://stackoverflow.com/questions/4895294/c-virtual-keyword-for-functions-in-derived-classes-is-it-necessary http://stackoverflow.com/questions/4895294/c-virtual-keyword...). Using 'final virtual' only makes sense for the second use, but is legal in the first context because of the re-use of the 'virtual' keyword.
plorkyeran 13y ago
Nonvirtual functions are effectively always final; if you have a pointer to a Foo which has a nonvirtual member function Bar, then you will always call Foo::Bar even if the thing being pointed to is actually an instance of a subclass that defines its own Bar member function. Using final without a base class only makes sense if you don't actually want virtual semantics but specifically need the function to be in the vtable for some reason (such as for COM).
IvoDankolov 13y ago
Yes, you are missing something, which is a bit of a quirk of C++. Normally, having two functions with the same signature in a parent and child class results in overloading. struct A { void f() {std::cout << "A";} }; struct B : A { void f() {std::cout << "B";} }; //.,... A a = B(); B b = B(); a.f(); b.f(); b.A::f(); This would print ABA, as the child's f() function simply hides the parent one when working in the context of B(), but it does not override it. Now, what virtual does is it tells the compiler, "from here on out, resolve clashing signatures for this function in child classes by overriding. I'm sure you know how our example changes when you mark f() as virtual. That's all old news, though. The more interesting bit, final, acts like so: from here on out, prevent overloading in child classes. Now, that only makes sense in the context of virtual, so that's the only place where you're allowed to use final, and here the actual difference to the first example becomes apparent. You see, final does not negate virtual, what it actually does is completely lock up the function signature from being used in any child classes. Adding virtual final to our example would not cause B's function to hide A's - it will simply not compile. If you think that's all pointless semantics, you are absolutely right. Locking up names is not the point of "final". In fact, declaring something as virtual final in the base class is completely pointless from any practical standpoint. The actual problem that final is meant to solve is this: As I mentioned earlier, virtual changes the way resolving names works in child classes forever. These two pieces of code are absolutely equivalent. struct A { virtual void f() {std::cout << "A";} }; struct B : A { void f() {std::cout << "B";} }; And: struct A { virtual void f() {std::cout << "A";} }; struct B : A { virtual void f() {std::cout << "B";} }; Therein lies an interesting dilemma. What if I wanted to prevent any child class of B, and only B, from changing the implementation of f. Under C++03, that is not possible. In C++11, final solves that. But why go through the trouble of introducing a new keyword - and a keyword that is only a keyword in class and function declarations to boot (Holy context dependent grammar, Batman!) - and not just drop the virtual qualifier? Backwards compatibility - ever a dreaded thing when you wish you could undo your old mistakes. It isn't all that big of a deal (said the C++ developer about every strange rule in the language, ever), though, since when you use "final" for the intended purpose, you won't actually be needing the virtual qualifier. struct A { virtual void f() {std::cout << "A";} }; struct B : A { void f() final {std::cout << "B";} }; struct C : B { void f(); //I'm afraid I can't let you do that. };

general_failure 13y ago

Great slides. This is the first time I am seeing a direct C++03 and C++11 comparison. Makes it much easier to understand. That said, c++11 is a language that wants to be everything. Functional, object oriented, procedural, imperative, declarative and what not. The end result is slush.

eksith 13y ago
Slush is possible in C++03 as well. I'd say C++11 is trying to be humane as possible in that regard and not destroy the program (or the output) on account of programmer idiosyncrasies, no? What I would much rather prefer is a "from scratch" approach to learning C++11 (assuming no prior knowledge about programming, but having a basic knowledge about memory etc...) That would really help curb the tide of novice programmers seduced by sexier languages that have no concept of safety, efficiency and correctness.
- asdfgP 13y ago
  A good introductionary book about C++11 is "C++ Primer": http://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/0321714113 http://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/032171... What I like about this book is that it teaches you the new C++ way right from the beginning. Rather than walking you through the history of C, it gets you to the modern practices immediately. Disclaimer: I have only read the first 10% of the book myself, but so far I like it.
stephen_g 13y ago
Slush? Depends how you use it. It's extremely easy to write horrible C++ code, but when used by a talented developer I think the result can be extremely elegant. I like how it's a lot more expressive than C, but without the needless verbosity of a language like Java.
- betterunix 13y ago
  C++ still has quite a bit of needless verbosity. You need to explicitly specify how variables should be captured in lexical closures. You need to explicitly choose weak pointers versus non-weak pointers. There are few useful defaults; you are forced to explicitly write a lot of boilerplate as a result. It may be better than Java, but that is not saying much.

JoshTriplett 13y ago

Personally, I'd like to see some of these features added to C where they make sense. Raw strings, bind, lambdas, constexpr, and ranged for loops would all make sense in C.

gcr 13y ago
How could lambdas make sense in C? Keeping closures around means having to keep free variables around. C doesn't have garbage collection, so it would be quite awkward to establish conventions about who gets to free the variables that each closure references.
- betterunix 13y ago
  How does any of that not apply to C++?
  - deleted 13y ago
    [deleted]
  - kybernetyk 13y ago
    Closures work pretty great with std::shared_ptr.
    - betterunix 13y ago
      Unless you have a cycle.
- JoshTriplett 13y ago
  Take a look at the "blocks" extension to C, in LLVM. It includes mechanisms to handle the lifetime issues, though it does still require explicit memory reclamation of blocks.
iambvk 13y ago
I agree! I found no libraries that give std::bind functionality in C and GCC extensions also doesn't offer any solutions.

dakimov 13y ago

Very concise. Great!

kubov 13y ago

Even with those enhancements, C++ remains incredibly complex language, with such a great variety of features the learning curve would be rising very slowly over time.

tspiteri 13y ago
with such a great variety of features the learning curve would be rising very slowly over time. That is not necessarily true. The point behind C++11 is to provide new features that are easier to learn than the features they replace. So C++11 on its own has a lower learning curve than C++03. Of course, if you're maintaining older code, then your point stands, and the learning curve would be rising because of the extra new features.

CamperBob2 13y ago

string test=R"(C:\A\B\C\D\file1.txt)"; Hmm, that's ugly. Why are those parens needed?

vinkelhake 13y ago
You can prefix the left parenthesis with a string. You then repeat that string after the right parenthesis. By doing this you can include sequences in the raw string literal that would have otherwise terminated it. R"foo(xyz)")foo";
bskari 13y ago
The parentheses are used as delimeters so that you can use quotes in the literal. string test = R"(the Star Trek catchphrase "Beam me up, Scotty" did not appear)"; If you want to use quotes in the string, you can add up to 16 chars to the delimiter, but you still have to use the parentheses. string test = R"[de=limiter!(the (Star Trek) catchphrase "Beam me up, Scotty" did not appear)[de=limiter!";

alisnic 13y ago

proposal: cpp.wikipedia.org - to categorize and store all the stuff cpp had and have. </sarcasm>

JulianMorrison 13y ago

I just have to thank my lucky stars i don't work with it. It's like they are trying to iterate a power saw into an aeroplane by gradually adding features while remaining backwards compatibility as a power saw. Please hurry up and finish Rust, is all I can say to that.

Erwin 13y ago
I think it's a great update. Everyone already using C++ on a platform that has the required tooling (also considering libraries, IDEs) will benefit from updating. Compare to that Python 2.x to Python 3.x. I have no interest in updating my XX kloc of Python code so that... unicode becomes cleaner?

thebear 13y ago

This is a great overview. However, in order to use the new C++11 features correctly and avoid pitfalls, one must dig a bit deeper. A good example is auto and decltype: http://thbecker.net/articles/auto_and_decltype/section_01.html http://thbecker.net/articles/auto_and_decltype/section_01.ht...