Biggest Changes In C++11 (and Why You Should Care)

Esther Schindler writes "It's been 13 years since the first iteration of the C++ language. Danny Kalev, a former member of the C++ standards committee, explains how the programming language has been improved and how it can help you write better code."

Comments

Cruft removed?

[kikito]

I really like that they added new stuff to the language but ...

Have they *removed* anything at all from it? That's the only way I could get interested in that language again.

But...

[DeathToBill]

This is news for nerds. Stuff that matters. I thought /. abandoned this stuff ages ago...

Re:Nice but...

[daid303]

If you are putting binary flags in enums then you are using them wrong. And that's why you are no longer allowed to do so. It's a GOOD thing.

You want bitfields: http://msdn.microsoft.com/en-us/library/ewwyfdbe(v=vs.71).aspx

Re:Nice but...

[Arlet]

Bitfields are not as flexible when you want to change several different bits (belonging to different fields) in a word using a single write.

Re:C++0x

[LighterShadeOfBlack]

C++0x is C++11. C++0x was a placeholder name until they actually knew what year it would be finalised.

Re:Nice but...

[DrXym]

Templates are fine for little classes but they got so abused by STL that it was not uncommon to see trivial syntax errors turn into enormous cryptic compiler errors spanning multiple lines of nested templates and typedefs, half of whom you'd never heard of. After poring over this enormous error for minutes or longer you might eventually discover you missed a * off some declaration.

Does TFA actually explain things?

[SanityInAnarchy]

It's been awhile since I've had to do any C++, so maybe I'm just missing something, but it seems like either there's a lot of retarded functionality here, or there's a lot of TFA which introduces a feature, even motivates it, but doesn't actually explain what the new version looks like. For example, with "Rvalue References":

void naiveswap(string &a, string & b)
{
string temp = a;
a=b;
b=temp;
}
This is expensive. Copying a string entails the allocation of raw memory and copying the characters from the source to the target...

Ok, first, what? I thought standard library string implementations were supposed to be efficient, and include some sort of copy-on-write semantics, which would (I would hope) make the above a shuffle-pointer-around instruction instead of a copy-data-around instruction.

Second, here's the newer, better syntax:

void moveswapstr(string& empty, string & filled)
{
//pseudo code, but you get the idea
size_t sz=empty.size();
const char *p= empty.data();
//move filled's resources to empty
empty.setsize(filled.size());
empty.setdata(filled.data());
//filled becomes empty
filled.setsize(sz);
filled.setdata(p);
}

Regarding the first comment, no, I really don't, unless the point is that this is what the code for "moving" would look like if implemented in older versions of C++. But also:

If you’re implementing a class that supports moving, you can declare a move constructor and a move assignment operator like this:
class Movable
{
Movable (Movable&&); //move constructor
Movable&& operator=(Movable&&); //move assignment operator
};

Ok, cool... But where is this used in the "moveswapstr" example? Does this make the "naiveswap" example automagically faster? Or is there some other syntax? It doesn't really say:

The C++11 Standard Library uses move semantics extensively. Many algorithms and containers are now move-optimized.

...right... Still, unless I actually know what this means, it's useless.

It looks like there's a lot of good stuff here, and the article is decently organized, but the actual writing leaves me balanced between "Did I miss something?" like the above, and enough confusion that I'm actually confident the author screwed up. For example:

In C++03, you must specify the type of an object when you declare it. Yet in many cases, an object’s declaration includes an initializer. C++11 takes advantage of this, letting you declare objects without specifying their types:
auto x=0; //x has type int because 0 is int
auto c='a'; //char
auto d=0.5; //double
auto national_debt=14400000000000LL;//long long

Great! Awesome! Of course, this arguably should've been there to begin with, and the 'auto' in front of these variables is still annoying, coming from dynamically-typed languages. But hey, maybe I can write this:

for (auto i = list.begin(); i != list.end(); ++i) ...

Instead of:

for (std::list<shared_ptr<whatever> >::iterator i = list.begin(); i != list.end(); ++i) ...

It's almost like C++ wanted to deliberately discourage abstraction by making it as obnoxious as possible to use constructs like the above. Anyway, that's what I expected the article to say, but instead, it says this:

Instead, you can declare the iterator like this:
void fucn(const vector<int> &vi)
{
vector<int>::const_iterator ci=vi.begin();
}

Re:Still playing catch-up to C#.

[Waffle Iron]

The saddest part about this whole C++0x ordeal is that they're still just playing catch-up to C#.

True. In particular, C++ is light years behind C# in patent FUD. And C++ hasn't even started work on requirements for a 100MB "managed environment" for users to install before running their apps. Nor have C++ developers chosen a monkey species after which to name its 2nd-class-citizen cross-platform implementation.

Why is a garbage collector even needed?

[ifrag]

What is the big fuss about getting a garbage collector anyway? Why does it even matter? Good C++ code shouldn't need a garbage collector. If memory was allocated within an object then the destructor should be taking care of it. And with shard_ptr (which people should start using) it's taken care of within there anyway. Is this wanted so everyone can start coding sloppy C++ and forget about the delete calls? I suppose for those using some 3rd party library that behaves poorly and is totally out of your control it could be nice to stop that from leaking all over. Still, it should have been done right in the first place.

I suppose there might be some argument for preventing excessive memory fragmentation. Is there some other benefit to having one?

Re:13 years?

[siride]

I have to lol at the "constant win api changes" statement. The Win API bends over backwards for backwards compatibility. In Unix, especially Linux, outside of POSIX (which is fairly limited in functionality), backwards compatibility is almost a 4 letter word.