

Rundown of the newest features in C++11 [pdf] - octo_t
http://dl.dropboxusercontent.com/u/13100941/C%2B%2B11.pdf

======
general_failure
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.

~~~
stephen_g
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
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.

~~~
kybernetyk
> You need to explicitly specify how variables should be captured in lexical
> closures.

I prefer that to some "it's automagically captured" behavior (in the context
of C++). At least so I know and can choose if the closure captures a reference
or makes a copy - which can be a very important detail.

For the stuff I usually do in C++ I love this kind of freedom. For other stuff
where speed and/or memory layout/usage are not that important there are higher
level languages like Python or Common Lisp.

~~~
betterunix
It seems to me that you could just as easily _always_ create a copy of the
captured variable, and in cases where you want to capture a reference, just
create a reference to the variable and capture that instead. That is exactly
what you see people doing when they capture "smart" pointers. You would not
lose any freedom if captured variables were always copied, you would still be
able to avoid expensive copy operations as needed (or just fix the problem at
its source by making copying less expensive).

A high level feature like lexical closures should not get bogged down with
low-level details (like the mechanics of how variables are captured). It's a
waste of time and mental energy, distracting programmers from important issues
and making debugging more complicated and time-consuming. Spending time
deciding which method of capturing variables is faster screams "premature
optimization."

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

------
CamperBob2

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

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

~~~
bskari
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!";

------
JoshTriplett
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
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
How does any of that not apply to C++?

~~~
kybernetyk
Closures work pretty great with std::shared_ptr.

~~~
betterunix
Unless you have a cycle.

------
kubov
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
_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.

------
AldousHaxley
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?

~~~
IvoDankolov
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.
      };

------
thebear
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...](http://thbecker.net/articles/auto_and_decltype/section_01.html)

------
JulianMorrison
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
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?

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

~~~
vinkelhake
libstdc++ is still missing C++11-features. Regex and thread are still not
complete:
[http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#s...](http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x)

------
dakimov
Very concise. Great!

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

</sarcasm>

