Author Topic: Herb Sutter's brief look at C++11 (Read 19684 times)

Eóin · « **on:** October 31, 2011, 02:51 PM »

Herb Sutter, Microsoft's head C++/CLI guy and author of the famous Guru of the Week columns, has nice little overview of some of C++11 new features over on this blog. It's really worth checking out.

The C++11 standard offers many useful new features. This page focuses specifically and only on those features that make C++11 really feel like a new language compared to C++98, because:

They change the styles and idioms you’ll use when writing C++ code, often including the way you’ll design C++ libraries. For example, you’ll see more smart pointer parameters and return values, and functions that return big objects by value.
They will be used so pervasively that you’ll probably see them in most code examples. For example, virtually every five-line modern C++ code example will say “auto” somewhere.
-http://herbsutter.com/elements-of-modern-c-style/

mouser · « **Reply #1 on:** October 31, 2011, 05:40 PM »

thanks for sharing this info -- going to read now.

Eóin · « **Reply #2 on:** October 31, 2011, 07:15 PM »

I must say I'm loving the few C++11 features that appeared in Visual Studio 2010. Can't wait to get developing with the fuller new standard library.

Jibz · « **Reply #3 on:** November 01, 2011, 02:05 AM »

Auto and range for alone will save a ton of typing (or a ton of typedefs)

.

Gothi[c] · « **Reply #4 on:** November 01, 2011, 02:33 AM »

Use auto wherever possible. It is useful for two reasons. First, most obviously it’s a convenience that lets us avoid repeating a type name that we already stated and the compiler already knows.

// C++98
map<int,string>::iterator i = m.begin();

// C++11
auto i = begin(m);

Second, it’s more than just a convenience when a type has an unknown or unutterable name, such as the type of most lambda functions, that you couldn’t otherwise spell easily or at all.

I'm not sure how much I like this... I mean,.. Isn't this type of thing exactly why we have typdef's ?
At least a typedef still gives you an idea of what type a variable will be, or at least make it relatively easy to look up the type definition in the code. Looking up the return value of begin() in stl seems like more of a pain in the rear, and this is just a simple example... :S

[Select]

typedef std::vector<std::string> strvector;

// ...

strvector foo = func(); // <- this seems more useful/readable than:

auto foo = func(); // <- no idea wtf foo is from looking at it.

mouser · « **Reply #5 on:** November 01, 2011, 09:12 AM »

Yeah i had the same gut reaction that gothic had.. that i like to be able to see what the type the variable is.. but i suppose we always still have that option.

I can see how the auto could come in very handy for those very short sections of code where you are using convoluted type iterators, which are a pain to type out for no good reason. I would just be wary of overusing it.

Eóin · « **Reply #6 on:** November 01, 2011, 09:16 AM »

With the likes of iterators I think it's a great thing, after all you don't want to care what the actual type of an iterator is, just that it behaves like you expect it to. It's duck typing but with the compiler verifying everything at compile time rather than forcing you to deal with runtime errors.

For the example you give, well I agree with you. But then foo is a local variable, likely it's lifetime is pretty short and it's type isn't as important as that it behaves as a vector-ish of strings. If your code specifically requires it to be a std::vector you can be more specific.

auto isn't necessarily meant to be used everywhere.

[edit] mouser beat me to saying much the same thing

Stoic Joker · « **Reply #7 on:** November 01, 2011, 11:22 AM »

Sounds like a great way to make code disposable, because coming back at a snippet months later it wont be real clear what the hell it does if it isn't commented thoroughly. ...And then you're just changing what you have to type (not eliminating it).

Jibz · « **Reply #8 on:** November 01, 2011, 01:06 PM »

Well, I guess time will tell

Eóin · « **Reply #9 on:** November 01, 2011, 01:50 PM »

Sounds like a great way to make code disposable, because coming back at a snippet months later it wont be real clear what the hell it does if it isn't commented thoroughly.
-Stoic Joker (November 01, 2011, 11:22 AM)

If misused sure, but I don't believe features should be left out because they could be misused. Also when you consider polymorphism and generic coding, both present in C++ for years now, this auto isn't exactly a whole new paradigm anyway.

mwb1100 · « **Reply #10 on:** November 01, 2011, 02:09 PM »

Also, "auto" has been in C# for a while now (is it in Java?) - as far as I know, it's been pretty well received. I don't hear a lot of people saying that it shouldn't be used, that it's been a mistake, or that it's caused problems.

Tuxman · « **Reply #11 on:** November 01, 2011, 04:31 PM »

C++11 is meh. I mean, lambda functions, wtf are they good for? Especially combined with "auto". So C++15 or something will maybe allow us to drop the type completely, let's call it "C++ PHP Edition". Oh wait, PHP introduced types...

Stoic Joker · « **Reply #12 on:** November 01, 2011, 04:54 PM »

Sounds like a great way to make code disposable, because coming back at a snippet months later it wont be real clear what the hell it does if it isn't commented thoroughly.
-Stoic Joker (November 01, 2011, 11:22 AM)

If misused sure, but I don't believe features should be left out because they could be misused. Also when you consider polymorphism and generic coding, both present in C++ for years now, this auto isn't exactly a whole new paradigm anyway.
-Eóin (November 01, 2011, 01:50 PM)

It is to me ... But most of my code is a ramshackle variation on pure C.

Eóin · « **Reply #13 on:** November 01, 2011, 06:08 PM »

You should start using Boost libraries, they get you thinking in the STL way. And once you do you won't go back!
Or at least I didn't.

Stoic Joker · « **Reply #14 on:** November 01, 2011, 06:46 PM »

You should start using Boost libraries, they get you thinking in the STL way.
-Eóin (November 01, 2011, 06:08 PM)

Hm... Well as long as it compiles into something that does not require any run-times, I just might give it a shot. VB soured me on that game years ago. I like a zero presence binary that'll just run regardless of what I toss it on (I'd best qualify that last part with Win2k & up...

).

Eóin · « **Reply #15 on:** November 01, 2011, 07:22 PM »

Yep, most of it it header only, so all gets compiled in. The other stuff is built as static and dynamic libraries. If you link against the static ones then there are no extra DLLs that need to be shipped with EXE. Build boost takes a lot of time and needs a lot of hard disk space. v 1./47 uses 10GBs for me, 3.5 GBs when NTFS compression is turned on. That's for 8 versions; debug/release * static/dynamic * x86/x64.

The EXE size will grow though, generic coding generates loads of code, the idea being that the compiler optimizes each version it generates for the specific types that are used by your program.

phitsc · « **Reply #16 on:** November 03, 2011, 12:02 PM »

I will use auto like crazy. I will actually use it wherever possible. I think using auto will actually raise productivity. Lambdas will come in handy as well. They will finally allow us to get rid of the boilerplate functor code which is currently necessary to make effective use of some standard algorithms. Both of these are also a clear testimony that C++ is adopting important aspects of yet another programming paradigm (which I think is a good thing), namely functional programming. Even with auto, C++ is still a strongly typed programming language. auto does also not replace typedef, as the type of a lambda expression for example is only known to the compiler (if you want to assign the lambda expression to a variable).

f0dder · « **Reply #17 on:** November 18, 2011, 03:52 PM »

Sounds like a great way to make code disposable, because coming back at a snippet months later it wont be real clear what the hell it does if it isn't commented thoroughly. ...And then you're just changing what you have to type (not eliminating it).
-Stoic Joker (November 01, 2011, 11:22 AM)

If misused, yes - but if used correctly, it's going to make code a lot easier to read, because it reduces irrelevant line noise.

Iterating a collection is one example, already shown - it's pretty atrocious in old-style C++, and franky... You don't need all the information present in such a block, it's noise. What you're interested in 99% of the time is not how you iterate, it's what you're doing in each iteration. Simplifying the 99% is, by itself, a pretty good idea... and it makes the 1% where you have funky iterator needs stand out. That's good as well.

And for declaring variables - you already have the full variable type on the right-hand side of the assignment expression, duplicating it to the right is a waste of time, and nothing but line noise (unless you need to construct some concrete subtype, and assign it to a generic interface type... but that's another case of the specific and special use case that with C++11 doesn't drown in the 99%).

C++11 is meh. I mean, lambda functions, wtf are they good for? Especially combined with "auto".
-Tuxman (November 01, 2011, 04:31 PM)

It's good for writing expressive, elegant and succinct code... focusing on what's going to happen, instead of the (often irrelevant) minutiae of implementation details. It also lets you rethink API design - turning things inside-out can be quite beneficial.

You might see lambdas as just syntactic sugar for function objects, but they're the glue that makes functional-style programming feasible in C++... The STL algorithms used to be a real pain to use, it's much more interesting now we have lambdas.

And you get all this goodness while still having a strong statically typed typesystem, compiler-checked, and with pretty much the best damn performance of all of the higher-level languages.

So C++15 or something will maybe allow us to drop the type completely, let's call it "C++ PHP Edition". Oh wait, PHP introduced types...
-Tuxman (November 01, 2011, 04:31 PM)

Please educate yourself

I will use auto like crazy. I will actually use it wherever possible.
-phitsc (November 03, 2011, 12:02 PM)

I think you can go a bit overboard, really. I wouldn't personally use it for primitive types - and I'm wary of using it for variables assigned to the result of a function call. Yes, an IDE will show you the type on mouse-hovering, but you don't always have an IDE... and even when you have, it takes precious milliseconds to deduce the type of a variable that way.

It depends on the code, though. If the variable type seems entirely irrelevant, and all operations are clearly understandable by looking just at the code using the variable, I might still use auto for function-return-assigned variables.

auto does also not replace typedef, as the type of a lambda expression for example is only known to the compiler (if you want to assign the lambda expression to a variable).
-phitsc (November 03, 2011, 12:02 PM)

Variables with "unspeakable (type) names" - I love that expression

Tuxman · « **Reply #18 on:** November 18, 2011, 04:49 PM »

Please educate yourself
-f0dder (November 18, 2011, 03:52 PM)

How?

f0dder · « **Reply #19 on:** November 18, 2011, 05:07 PM »

Please educate yourself
-f0dder (November 18, 2011, 03:52 PM)
How?
-Tuxman (November 18, 2011, 04:49 PM)

Try actually using some of the new features. Think about how they can change the way you code, for the better. Read blogs - I'd suggest checking out C# and Scala stuff, those have had lambdas and type inference longer than C++ (thus more information available, more experiences on "oops" and "aha!" moments) - and while having some FP traits, they're both a lot closer to C++ than the "real" functional languages.

Multi-paradigm ftw.

Tuxman · « **Reply #20 on:** November 18, 2011, 05:11 PM »

Never worked with Scala at all; but thanks for the hint. Not much time to read technical blogs this year.

f0dder · « **Reply #21 on:** November 18, 2011, 05:19 PM »

I'm a bit mixed wrt. Scala. Haven't had time to produce any code for it yet, only read some blog posts and reading through Dean Wampler's Programming Scala.

Parts of it seem very well constructed - it takes type inference even further than what C# does, in a good way. It reduces syntactic clutter, mostly in good ways (it takes a bit getting used to and a bit time accepting when you're used to C-style declarations; e.g. Scala has Pascal-style return type declaration). But after the "that ain't look like how we usually do things around here!" culture shock, most of it seems pretty sane. And some of the syntactic sugar lets you write pretty succinct and almost beautiful code.

Other choices seem outright weird, though. And some things seem to have roots in JVM limitations (like type erasure on generics... one of the biggest mistakes in Java/JVM, IMHO).

One of the biggest appeals of Scala, to me, is that it seems like a "mostly sane" language that does away with a lot of the teeeedious syntactic baggage of Java, adds features from C# I really like, but not tied to MS (not that whOracle is that much better, but we'll see how all that goes down).