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.'"
"Not a major overhaul"? (Score:5, Insightful)
I mean, it's not, but it makes it sound like C++11 is a minor update. Lambdas, auto, concurrency, are these minor updates? There's a lot of interesting stuff in C++11!
Re:I want auto! (Score:4, Insightful)
Now what happens when you change the name of a return type from a commonly used function? Have fun with your maintenance nightmare. If you are lucky the compiler will complain, if you are unlucky you break existing code without knowing it.
Re:I want auto! (Score:5, Insightful)
Prohibiting use of "var" is gross over-kill.
There are times where it's use is not recommended, certainly. But even in those cases, it can lead you to the point that there's a "bad code smell" where methods aren't named well, variables aren't named well, classes aren't named well.
var x = foo(); is definitely less readable.
But var x = new ComplexObject(); is every bit as readable, if not more so, because you don't have a redundant "ComplexObject" in the declaration. You always know exactly what type "x" is. It's also very useful in cases where the return type is a complicated generic. it saves a lot of typing, and is definitely more readable.
Here is a very good discussion on the benefits and uses of "var":
http://resharper.blogspot.com/2008/03/varification-using-implicitly-typed.html [blogspot.com]
Fascinating Software Engineering Challenge (Score:5, Insightful)
In some ways, a lot of what is being added to C++ makes me think of Scala, just less readable.
While the additions and extensions certainly make things more interesting and potentially more powerful/easier for the *individual* programmer, I look forward to seeing what sort of interesting train wrecks happen when larger teams try to make use of these features. I certainly hope the debuggers are being updated to be useful when someone's written a template that uses a #define'd macro to specify a closure that is passed through an anonymous function, etc.
This strikes me as the next generation's 'multi-threading' -- where almost every programmer claims they can handle multi-threaded programming, but very few actually do it well. Particularly in teams when interactions require coordination. Going to take a whole new round of winnowing the wheat from the chaff when it comes to finding developers who can actually use these features well without driving their coworkers insane.
Not seeing (1) (Score:5, Insightful)
I don't think you'll see a lot of people flaming C++, there just aren't that many people that care one way or the other anymore.
I think some of the new features look nice but mainstream use has been shifting away from C++ for a while and I'm not sure I see these new features drawing many back...
Re:George Bjarne Lucas Stroustrup (Score:4, Insightful)
Re:I want auto! (Score:5, Insightful)
Because var still works within the type system and gives you compile-time errors, and casting to object is a massive sledgehammer that delays errors until runtime (with all of runtime error checking's glory, like only failing some of the time, which you can basically read as "never on a developer's machine, sometimes on TQA's machine, and always on a customer's machine (unless support is on the phone with them)"), and a stupid idea in general (I'm looking at you, Objective-C!).
Re:In practice it's like a different language. (Score:5, Insightful)
Re:"Not a major overhaul"? (Score:5, Insightful)
Take goto, which is all that's really needed for modern programming. Using goto, you can implement subroutines (gosub like functions), while and for loops, etc. But each time you implement one of the higher constructs, your implementation will be slightly different. And if you force yourself to use the optimal implementation all the time, you'll just be writing a lot of boiler plate code. So having functions and while loops implemented as language constructs is a good thing. Similarly, std::thread + lambdas is a great addition.
Re:In practice it's like a different language. (Score:5, Insightful)
Don't be a zealot, pragmatic programmer should find the right trade-off between reusing code and writing an optimal one for a specific problem/area. Nothing can be optimal in all cases - sometimes you need to be as close to hardware as possible [beyond3d.com] at the expense of unreadable/inflexible code (for me, those are the most interesting and challenging areas), and sometimes you only care about maintainability of your code by a disposable programming drone.
Re:In practice it's like a different language. (Score:5, Insightful)
>Time to join the 21st century grandpa. FILE* leaks.
Hell no. And get off my lawn.
printf() isn't typesafe, but it's a fuckton more readable than all that cout formatting stuff. Also, the fact that it's not typesafe isn't really an issue if you don't suck - trivial unit testing will pretty much show any problems immediately. Besides, gcc/g++ is nice enough to warn you about egregious ones now.
FILE* leaks? I assume by this you mean when sloppy programmers fail to close their files and you start burning through file descriptors. Sounds like a bug to me, and again, stop sucking. Or do what we do - throw an object with a destructor containing fclose() around it. Then you get all the awesomeness of of FILE* (including those awesome formatting commands like fprintf and fscanf) without the danger of your file staying open when something goes nuts.
Why on earth would you want memcpy() to call anything? It's a low level byte move. Anybody with five minutes of familiarity with it should know that. If you wanted something different, use the assignment operator.
void* have all sorts of applications, most recently to me in writing architecture neutral VMs where really all the native machine knows is that it's moving around some sort of pointer.
Now the custom string and array classes? That I'll agree on. Troll on.
Re:In practice it's like a different language. (Score:0, Insightful)
Time to actually go out and build a real system, D-bag. See, throughout the process of building real products that need to work properly, it becomes apparent that while some "features" of new languages are nice and helpful at times (and they really are), most of the hoo-ha around new languages and such is just BS. If your chewing up memory because your cannot fclose() your FILE ptr.... well then you suck. If you think memcpy() should do Deep Copies... well then you, again suck. And for that matter, wtf is wrong with 'void'?
All these modern niceties won't save your miserable ass if you suck. You have been brainwashed. It's like people who walked around saying "goto is evil, there is always a better way". Those people have no clue. Chances are, if you can't write good C code, you wont write good C# code either. It's just that C# (and everything else these days) gives you a false sense of security.
Re:In practice it's like a different language. (Score:3, Insightful)
#warning rant coming
"printf instead of std::cout"
I love c++, but it definitely has some dark spots, even still the long overdue c++0x update (c++11 whatever). Thank deity we finally have standard smart pointers, better templates in various ways, move semantics, etc. It was really necessary to finally have that, even if it was a decade late (I'm sure we lost quite a bunch of good c++ programmers and projects to more newfangled languages in the delay). Even though we often won't be able to use it until all compilers (and developers) in use for a certain codebase are updated, it is a start.
c++ streams... After exceptions the second worst mistake in c++... c++ needs something good for that functionality, but streams and exceptions don't help.
Beware of std::cout, it is not thread-safe and is a gigantic pain in the expletive for outputting formatted text. The utility of overloading the shift operator for interfacing with streams is overrated. std::endl is a curse word. streambuf is an ugly hack.
while std::string is usually an improvement over the plain 'char *', it also is as often overkill as it often is underpowered. Why else would so many people have their own string class? Why would Qt have QString? It's because std::string and fstreams are severely lacking... standard c++ needs more syntactic strength in tokenizing, parsing, formatting, transforming, combining, and type-converting of string content. What is there, in the standard, is, well, imho kludgy. I'm not saying that I have the answer to what exactly it needs, it just needs something better.
c++ still has a lot of catching up to do. Libraries like boost should really only have their sandbox and legacy code left, and libraries like qt shouldn't need to redo/replace basic functionality. It should be possible to get a proof of concept implementation (aka badly optimized but mostly functional and not too many bugs for a demo or trial) working quickly as easy in c++ as it does in certain other languages. Until then, it should work hard to catch up before we lose most programmers to other languages.
Re:In practice it's like a different language. (Score:5, Insightful)
printf() isn't typesafe, but it's a fuckton more readable than all that cout formatting stuff
Readable? Meh. Localisable? Now that is an important attribute. Consider this trivial bit of code:
You want to localise this, so you wrap each string in a function that returns the localised version (by the way, gcc and clang have an attribute that you can put on functions that says if the output is safe to use as a format string in any case where the input is). So now you have something that looks like this:
Okay, no problem. Now let's consider the C++ equivalent:
Harder to read? Maybe, but the tokens are all in the order that they'll appear in the output, so I'll give C++ that one. Now let's localise it. How about something like:
That's fine, right? No more complex than the C version. Well, almost. Let's make French the target language. We want to turn 'the black cat' into French. Now we have a problem. In French, the word order is different. The result we want has the colour after the noun. No problem in the C version, the format string is just translated as "Le %2$s %1$s". The arguments are reversed (well, it's a little more complex because you also need agreement between the noun and the article, but I'll skip over that for now - it can be solved in the same way). What about the C++ version? Well, because the word order is in the code, not the data, you need different code paths for English and French. And that's just with a three-word sentence. Now consider the kind of sentence that actually appears in a typical UI. Consider German word-order rules. Your simple C / Objective-C strings file has to be replaced by a huge tangle of C++ code.