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

http://dl.dropboxusercontent.com/u/13100941/C%2B%2B11.pdf

by octo_t • 13 years ago

67 36 13 years ago

dl.dropboxusercontent.com

Game_Ender• 13 years 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• 13 years 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• 13 years ago

According to the metadata contained in the PDF file the creation date of this file is 9 January 2013.

plorkyeran2• 13 years ago

4.7's thread implementation is missing sleep_for, and possibly some other stuff. <regex> is still mostly not implemented in 4.8.

vinkelhake2• 13 years ago

libstdc++ is still missing C++11-features. Regex and thread are still not complete: http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#s...

AldousHaxley• 13 years 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• 13 years 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-...).

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...). 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.

plorkyeran2• 13 years 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• 13 years 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• 13 years 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• 13 years 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• 13 years ago

A good introductionary book about C++11 is "C++ Primer": 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• 13 years 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.

betterunix4• 13 years 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.

pjmlp• 13 years ago

> That said, c++11 is a language that wants to be everything. Functional, object oriented, procedural, imperative, declarative and what not.

You can state the same for any multi-paradigm language.

jadyoyster• 13 years ago

All those "paradigms" are artificial distinctions and can be used together perfectly well.

Why do you consider mixing them bad?

JoshTriplett2• 13 years 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• 13 years 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.

betterunix4• 13 years ago

How does any of that not apply to C++?

JoshTriplett2• 13 years 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• 13 years ago

I agree!

I found no libraries that give std::bind functionality in C and GCC extensions also doesn't offer any solutions.

smegel• 13 years ago

The main thing C needs from C++ is object destructors and RAII. It would be easy to denote a function as the cleanup operator for a struct, and the compiler already knows when variables go out of scope, valuable information that is currently not used for much. auto/shared pointers would save a lot of memory management pain in C.

Also function templates that would allow such things as a fast generic sort routine without lots of function pointer dereferences would be nice.

There's nothing else in C++ i can't live without.

dakimov• 13 years ago

Very concise. Great!

kubov• 13 years 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• 13 years 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• 13 years ago

   string test=R"(C:\A\B\C\D\file1.txt)";

Hmm, that's ugly. Why are those parens needed?

vinkelhake2• 13 years 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• 13 years 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• 13 years ago

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

</sarcasm>

JulianMorrison• 13 years 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• 13 years 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• 13 years 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.ht...

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

Related Stories