News for hackers. Stuff that matters.
Re:Why C++ Sails When the Vasa Sank [pdf] by rrrrtttt on Monday June 23, 2014 @11:43PM (#7936089)
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.

Re:Why C++ Sails When the Vasa Sank [pdf] by mgraczyk on Tuesday June 24, 2014 @01:02AM (#7936263)
1. That's not true, you can use range based for loops over C array types. 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.

Re:Why C++ Sails When the Vasa Sank [pdf] by pbsd on Tuesday June 24, 2014 @02:57AM (#7936505)
> 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