Re:Current Proposals for C++17
by GFK_of_xmaspast on Thursday February 25, 2016 @01:46PM
(#11176665)
The last big change was c++11, and that was already five years ago.
[ Parent
| on HN ]
Forgetting about C++14?
C++14 just cleaned up a couple of minor things from C++11. It was essentially intended to be a point release.
C++17 is the first "big" standard change since C++11. It will likely be followed by a small bug fix revision, analogous to C++14, a couple of years later.
Wasn't a lot of memory safety and thread safety introduced in c++14?
C++11 introduced threading and a memory model for C++.
C++14 had relaxed requirements on constexpr, initializers in lambda captures, using auto for return type deductions, and a few other small tweaks.
C++11 had unique_ptr and shared_ptr, but C++14 helped with adding make_unique. In my opinion, that makes a big difference because now making a special unique pointer is an atomic operation in your program.
Re:Current Proposals for C++17
by Kristine1975 on Friday February 26, 2016 @01:59AM
(#11180177)
If only make_unique (and make_shared) worked with uniform initialization...
struct Foo {
int i;
float f;
bool b;
// No constructor
};
std::make_unique<Foo>(1, 2.3f, true);
Doesn't compile, since make_unique requires an appropriate constructor (see https://isocpp.org/files/papers/n3588.txt for the rationale).It also doesn't work when Foo's constructor is private, even when called from a function that would have access to this private constructor.
And this is my beef with C++: Yes it's powerful, and I quite like it, but you sooner or later hit these speed bumps that unnecessarily complicate things.
Re:Current Proposals for C++17
by GFK_of_xmaspast on Thursday February 25, 2016 @03:33PM
(#11177571)
I don't consider c++14 to be a big change.