8 ms·
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
by 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 ago1. 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