Stroustrup Reveals What's New In C++ 11 305
snydeq writes "Bjarne Stroustrup discusses the latest version of C++, which, although not a major overhaul, offers many small upgrades to appeal to different areas of development. From the interview: 'I like the way move semantics will simplify the way we return large data structures from functions and improve the performance of standard-library types, such as string and vector. People in high-performance areas will appreciate the massive increase in the power of constant expressions (constexpr). Users of the standard library (and some GUI libraries) will probably find lambda expressions the most prominent feature. Everybody will use smaller new features, such as auto (deduce a variable's type from its initializer) and the range-for loop, to simplify code.'"
Re:I want auto! (Score:1, Interesting)
Unfortunately I code in java these days.. chances that oracle will see the light? :-)
Really? When I implemented our code guidelines, one of the rules is prohibiting the use of 'var', c#'s version of auto.
I don't ever want to look at code and wonder, "what type is this variable?" You're trading off the convenience of coding it without having to look up the data type name for making it more difficult to maintain. Anytime I have a choice between maintainability and ease of coding it the first time, maintainability wins.
Re:"Not a major overhaul"? (Score:5, Interesting)
I've been using the C++11 for 6 months now in my own project (libbitcoin [libbitcoin.org]) and the new features and syntax really make your code sharper, clearer and better. C++ is no longer that unsafe language if you know how to code in it properly - you never really have to do any manual memory management if you use shared pointers.
constexpr allowed me to create compile time constants that are the function of a bunch of complicated expressions. Sure, I could just put the result in the code, but by using constexpr (a far more expressive metaprogramming utility than templates) I can document where those constants came from by using code. Neat huh!
Using variadic templates, I was able to write decorators that can be applied to any function. I simply wrap my functions with this class and then its operator() will be called before calling the passed in function object (which I can define using lambdas or std::bind now :)
auto means I no longer have to type std::vector>::iterator in every for loop. Likewise for (const transaction& tx: block.transactions) is much more terse and clearer.
The new features to the standard library are brilliant. Threading has never been easier: std::thread t(foo, x, y); will call foo(x, y) in a new thread. When I decide to finish the threads and then join them I call: t.join(); ... Simple.
As libbitcoin is highly asynchronous, I don't like to use exceptions (which thread does it originate in? where does it get caught? .etc). C++11 now provides the header which defines std::error_code(). An error_code object can be tested as a boolean (to see whether the error is set or not) or compared against an enum value (which you define). They also have an error message (which if you defined the enum value it is set to, you can also set the message), and also you can group different error code values into broader categories! Really useful for asynchronous programming.
std::atomic for a thread-safe counter (useful when you have multiple thread paths executing and want to see when they all finished - increment your counter by one after each path completes) and std::atomic for a thread-safe flag. ... That's off the top of my head. There are dozens of many small things like this. C++ was always my 'native' language, but now it's truly my home.
Re:I want auto! (Score:4, Interesting)
var my_object = new my_class();
v.s.
my_class my_object = new my_class();
Here using var just saves a few key struck (or a lot, in case my_class happens to be a type with a particularly long name). In any case the type of my_object is perfectly known and quite visible so I think using auto is just fine.
There are however cases that a complex type is used while we actually DO NOT care for the type per se. For example in C++ consider the case for a lambda function:
auto my_fun = [](int i) { return i * i; };
Here I actually don't care about the exact type of my_fun. All I care is that it take an int and returns an int which I can see clearly. Finally, another case could be situations in template programming where insanely complex types are used/generated and we don't want to (or even cannot) type them again and again. Also I guess in Java or C# you might get away by cheating and using an object (I hate it when people do that!) but we don't have that luxury in C++.
Some idiotic stuff too (Score:4, Interesting)
I guarantee you will quickly come to hate the new "narrowing" errors, for example any time int converts to float inside initializer curlies, or double to float. As a language feature, this lies firmly in the category of wanking.
That said, my code is all full of lambdas now, thankyou. On the other hand, lambda syntax is uglier than sin. While a lambda can do anything a lexically scoped nested function can, it is not pretty. Now obviously, there is no reason not to support proper lexically scoped nested functions, as GCC already does. Arguing that they are now unnecessary because of lambdas is, again, wanking. The practical fallout is that when you move a lambda-style helper function to global scope or to member status, you have a bunch of editing to do, to remove the ugly auto/lambda bits.
Another big disappointment is, nothing was done to address the good features C99 has that C++ does not. Designated initializers and variable size array parameters, to name two. Wanking again.
On the whole, there is too much wanking going on in the C++ stewardship process. Guys, you need to remember, C++ does not exist only as a means of compiling the STL.
Re:I want auto! (Score:0, Interesting)
Re:In practice it's like a different language. (Score:5, Interesting)
Now be careful, because inheritance was not really intended for code reuse. If it does help with code reuse, that's a positive consequence, but it's not what inheritance is for, first and foremost. See Liskov substitution principle and all that jazz.
Re:Not seeing (1) (Score:5, Interesting)
Mainstream use is shifting back to C++ since Microsoft decided that C++ was batter than C# (or at least Sinofsky and the Windows team decided that was the case). Herb Sutter has done a lot of presentations on the new paradigm at Microsoft - do a quick google.
Of particular note is the reason they're giving for this: in the datacentre native code reduces the amount of energy required to run your apps, and that adds up significantly if you're using dynamic or even JIT language.
Meh... (Score:3, Interesting)
Good for showing off.. bad for getting actual work done, esp for projects that last more then a year or two.
Re:For my next trick (Score:4, Interesting)
In one corner we have memory, which is 99% of the "resources" needed to be managed
Go ahead, count the number of calls to "Close" and "Dispose" in a real world C# or Java app. Then get back to us with some solid number for that 99% claim.
Simple example, open a file, write to it, let the dtor flush and close. If flushing fails, you won't know, because dtors can't return anything, and exceptions in dtors is a big no-no (because, incidentally, there's no GC to free the stuff). That's _wrong_.
Suppose you're right, and you detect that flush failed during close. What are you going to do?
Suppose furthermore that you have an exception in flight, and you've just had flush fail in your finally-block (assuming C#/Java). What are you going to do now?
If you want exception safety, you need RAII, period. If you have RAII, you might as well use it for memory.
Smart pointers are a lousy GC scheme that does memory badly (ref counting is inefficient, especially on MP systems, and cannot handle cycles)
Those claims that refcounting is inefficient are old, but somehow they only show up in synthetic tests. In real world apps, something written in C++ is invariably faster and more responsive than alternatives written in managed languages. That's precisely why C++ is still used far more widely for desktop apps, and is used almost exclusively anywhere perf really matters (like games).
And there's weak_ptr for cycles.
Re:For my next trick (Score:4, Interesting)
Oh, and before you mention weak references (to be totally honest, I am not even sure if there is a standard weak reference in C++)
std::weak_ptr in C++11. Been there for 7 years now (originally as std::tr1::weak_ptr), and for a few years before that in Boost.
I'll mention that very few C++ programmers know what they are.
That's the problem with those programmers, not the language. C++ is powerful and fast by design; that, unfortunately, also makes it complex by design. It's not a language for everyone, and Java and C# certainly have their very large niche. But C++ is a very powerful tool when used right.
The syntax of C++ is so crowded that the language is only used for low level stuff where the extra 5% performance boost is a big deal.
That's emphatically not true. I've repeated it several times already in this thread, and I'll repeat it again: most desktop software today is written in C++. Heck, even a fair bit of OS X software is written mostly in C++, especially if you look at the size of it (MS Office, Photoshop). The reason for that is that perf boost (relative to Java/C#) is more like 20% for common tasks; but, more importantly, there is a marked responsiveness improvement due to lack of GC. And responsiveness is some really subtle stuff - it's not quite the same as "fast", but it's very sensitive to stutter on the order of tens of ms (a delay over 100ms is already noticeable by the user).
You can write good UI software in managed languages, but then you need libraries that are themselves written in native code, at least rendering and input layer. Otherwise you end up with a clumsy pig like Swing.