c++11 to me was largely a quality of life improvement. Some other features that haven't been mentioned:

Non-static data member initialization - Being able to declare the default value of a member variable at declaration ( where it should have been ) instead of some constructor somewhere else. ( My personal favorite )

Delegating / Inheriting constructors - How many times have you had to write an init() because of multiple constructors.

constexpr - Kind of like a type safe macro's.

--Z

I also like the new initializer lists, because they make my code more clear in some common situations:

  for (int delta : {-8, -1, +1, +8}) {
    // ...
  }

  // ...

  std::map<std::string, std::string> dictionary = {
    {"spring", "muelle"},
    {"summer", "verano"},
    {"fall", "caida"},
    {"winter", "invierno"}
  };

Rant (slightly off topic):

And still, in 2014, Microsoft does not fully support the standard. The latest thing I came across: No defaulted move constructors or defaulted move assignment operators.

It's quite remarkable that the "convener" of the ISO C++ committee, Herb Sutter, is MS employee...

I have grown to accept MSVCs deficiencies. I can live with them when I'm being paid.

For my personal projects I have moved over to QtCreator + MinGW though. After some initial friction (QtCreator can be a bit quirky when you are not used it) the only thing I'm actually missing is MSVC's debugger.

Edit: Stroustrup actually summarizes my issues with boost quite well here

This made me lough:

"Some of the libraries are too clever for my taste. Sometimes, generality and simplicity coincide; in Boost, the balance is IMO too often so far towards generality that novices and average users are lost."

And this says Stroustrup!

The really annoying one for me was when std::shared_ptr<T> was in the tr1 namespace on some compilers (std::tr1::shared_ptr<T>) for seemingly a very long time. I had to use a macro to attempt to hack round it whilst fighting off suggestions of "use boost::shared_ptr<T>".

When using the 'using' keyword, you don't have to bring it into the 'global' scope, you can bring it into existing or new namespaces as well. Macroes aren't necessary.

#ifdef SOME_COMPILER
namespace std //Within the 'std' namespace...
{
    using tr1::shared_ptr; //...bring 'shared_ptr' down to the 'std' namespace.
}
#endif

[example]

Lambdas can only be defined and used inside functions:

O_o, wut? Lambda is a closure object - saying that it can only be defined / used inside functions makes as much sense than saying one can use/define the value 7 ONLY inside functions. Do not get confused that the lambda object is called "closure object" - that too is still just an object. In short, there is no such limitation.

Perhaps you meant that defining a capturing Lambda outside functions is conceptually kinda totally bonkers -> capture list requires function scope.


Another discrepancy i noticed:

Lambda object defines a few operators. One that seemed to cause a bit unfortunate/confusing wordings here is: type conversion operator to the underlying function type (only defined if the lambda does not capture anything - as otherwise the operator would not make any sense). IE. Lambda object is NOT just a function, however it might be possible to get a function pointer out of one via implicit/explicit conversion:

void (*snafu)() = [ ]()->void { ... } // this is legal through conversion operator
void (*snafu)() = [&]()->void { ... } // ... this is not as there is no applicable conversion.