It's different in the sense that it adds a whole lot of features, which makes it even more complex. It's not just the new features, but how they interact with old one. C++98 is still there, just underneath.
I, thankfully, haven't used C++ much in the past few years after using it nearly exclusively for about a decade, but the one thing about working in it that will always stick with me is how virtually every project would eventually have like 8 different string classes contained within it for much the same reason (different libraries and/or OS level APIs would use different string classes, often their own), and this is well after std::string/wstring were a thing.
That's the real danger with a sprawling language like C++, IMO. Not that you have to use every bit of it in your own code (in your own code you can get by with a very small subset), but the fact that because there's little true consensus on which bits of it to use it, projects with external dependencies (that are also in C++) generally grow to use not only the entire language and standard library in different places, but also a bunch of badly hacked up reimplementations of the standard library that come along with some of those dependencies.
In various circumstances you may want: string_views, copy_on_write_buffers, small_buffers (for small-string optimization), native arrays of chars, std::arrays of chars, std::vectors of chars, tries, and so on.
In all of the above cases, you should be able to write: auto firstSpace = std::find( begin(myCharContainer), end(myCharContainer), ' '); ...to get an iterator to the first space in your container.
And on top of all that, you could make versions of begin() and end() that return iterators that respect various character encodings.
1) You can create range for loops over containers:
for (auto x: vec) {
foo(x);
}
2. You can create shared pointers using make_shared, but you can't create unique pointers using make_unique. What's worse, if you define your own make_unique function, your code will eventually break because it's already decided that C++14 will have its own make_unique.
I'm sure all of this will get fixed eventually, but frankly I don't have more patience for this. The root cause is that the C++ process is broken and is lead by incompetent clueless people.
2. As you mentioned, make_unique is a part of C++14 (although it will still be missing make_unique<T[]> ). I don't see the big deal is though since libc++, libstdc++, and VS2013 already have a compliant make_unique implementation.
This is not true -- see §20.9.1.4 of the C++14 draft [1]. make_unique is defined for array types with unknown bound (i.e., T[]), but it is deleted for array types of known bound (e.g., T[5]). So to make an array of 100 default-initialized `int`s,
auto array = std::make_unique<int[]>(100);