4 ms·

The addition of a whole host of features in C++11 makes the language more consistent and easier to comprehend. The talk gives examples of this (auto variables,

by pradn 12y ago

The addition of a whole host of features in C++11 makes the language more consistent and easier to comprehend. The talk gives examples of this (auto variables, range for loops, etc.)

georgemcbay 12y ago
Of course, as soon as you have to use any external libraries written for C++98 you are right back to having to understand both. 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.
- humanrebar 12y ago
  The problem with string classes, including std::string, is that they are object oriented. The things you do with a string should be orthogonal to how the string works. When you think about it std::string is really a string buffer. And if we had good string algorithms, it wouldn't be much more useful than vector<char>. 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.
rrrrtttt 12y ago
Initially when you start with C++11 you get the impression that the old heap of idiosyncrasies was fixed, but then you realize there's a whole bunch of new ones. My most recent peeves: 1) You can create range for loops over containers: for (auto x: vec) { foo(x); } but then if you want to do the same over a C array, you have to define your own wrapper with begin() and end() functions. 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.
- mgraczyk 12y ago
  1. That's not true, you can use range based for loops over C array types. http://stackoverflow.com/questions/7939399/how-does-the-range-based-for-work-for-plain-arrays http://stackoverflow.com/questions/7939399/how-does-the-rang... 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.
  - pbsd 12y ago
    > although it will still be missing make_unique<T[]> 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); [1] http://isocpp.org/files/papers/N3690.pdf http://isocpp.org/files/papers/N3690.pdf

by pradn 12y ago

The addition of a whole host of features in C++11 makes the language more consistent and easier to comprehend. The talk gives examples of this (auto variables, range for loops, etc.)

georgemcbay 12y ago

Of course, as soon as you have to use any external libraries written for C++98 you are right back to having to understand both. 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.

humanrebar 12y ago
The problem with string classes, including std::string, is that they are object oriented. The things you do with a string should be orthogonal to how the string works. When you think about it std::string is really a string buffer. And if we had good string algorithms, it wouldn't be much more useful than vector<char>. 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.

rrrrtttt 12y ago

Initially when you start with C++11 you get the impression that the old heap of idiosyncrasies was fixed, but then you realize there's a whole bunch of new ones. My most recent peeves: 1) You can create range for loops over containers: for (auto x: vec) { foo(x); } but then if you want to do the same over a C array, you have to define your own wrapper with begin() and end() functions. 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.

mgraczyk 12y ago
1. That's not true, you can use range based for loops over C array types. http://stackoverflow.com/questions/7939399/how-does-the-range-based-for-work-for-plain-arrays http://stackoverflow.com/questions/7939399/how-does-the-rang... 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.
- pbsd 12y ago
  > although it will still be missing make_unique<T[]> 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); [1] http://isocpp.org/files/papers/N3690.pdf http://isocpp.org/files/papers/N3690.pdf