Hacker News Reader

Comment by lacampbell | Hacker News Reader

What are the big new features of C++17? C++11 seemed like the last big change - I think the only reason I bother using "-std=c++14" is for "make_unique".

View on HN

The major user visible features of C++14 were polymorphic lambdas, generalized lambda capture, proper constexpr, member initializers and return type deduction. I use most of these everyday.

For C++17 the biggest features are structured binding, which is the first step toward pattern matching, and deduction of template parameters for class types.

Other features like fold expressions are realy meant for library writers.

The standard library did get variant and optional whixh arw pretty cool.

Oh how I envy your use of C++14 every day. Here we are still trying to migrate off VC2008 and C++2003.

Variant and optional would be really useful if only I could use them. One day, one day...

(ps doesn't stop me writing using these new features at home on other projects)

The lack of generalized lambda capture was one of the biggest idiosyncrasies of C++11, given its focus on move semantics.

Even in with the last draft it still not possible to easily move-capture a variadic parameter pack; it is a fairly esoteric feature and there are workarounds, but it is still annoying.

Please always use "-std=c++14" when you can. There are a lot of subtle differences between c++11 and c++14.

That is a nightmare fuel comment-- are people's valid C++11 codebases going to execute in materially different ways when someone flips the std flag to c++14?

It seems that the change from C++11 to C++14 broke the semantics of "inline". I'm not sure who thought that was a good idea. You'll find that code that used to compile no longer does. Reverse-engineering the failure all the back to the language specification is VERY time consuming. Finding the right compiler switch (--std) will also take a while, assuming you even know there IS such a compiler switch. It also seems (I might be wrong) that gcc defaults to C++11 but g++ defaults to C++14.

Breaking legacy code without access to the original authors makes maintaining that code extremely difficult. Can you rewrite all of the "inline" instances in a 1M line C++ program without side-effects such as performance loss? When the lead programmer requires C++17 for their spiffy new code, are you the person who has to rewrite the "broken legacy code"? Does your IDE know all of the standards?

They should change the language name each time, such as "Alpha", "Beta", "Gamma", etc. so you can say that you "know" the "Beta" language. As it is I don't know anyone who can seriously claim to know "C++".

"C++ Standard" is an oxymoron.

I find it easier to ask what standard they work to. If someone says "I write C++", I would ask "what version?" as there is a significant gulf between 2003 and 2011 standards, for example.

Or, as is very common, they are not sure and it you will know that they don't know enough C++, or are in danger of writing C++ like it was C.

If someone says "I play the guitar" and you ask "acoustic, electric? hollow bodied?" and they don't know, you'd be surprised.

If someone says "I own a Volkswagen Golf" and you asked what mark (4, 5, 6 or 7) and they didn't know, you'd assume they knew nothing about they car or didn't have to replace any parts on it, even simple things like windscreen wipers as they'd have bought the wrong ones.

It's the same with C++ - the spec makes a huge difference so we should probably all be aware of what we're writing.

....or, they look up in the manual when they have to change the wiper blades.

I was implying that they haven't bought new blades because a Mk4 wiper blade will not fit a Mk5. You cannot shop for wiper blades without knowing what your model and mark is.

But you can forget, especially knowing it'll still be in the manual the next time you buy wiper blades.

What changes are you referring to?

cppreference[1] (which, granted, is not authoritative) does not document any changes in inline semantics in C++14.

[1] http://en.cppreference.com/w/cpp/language/inline

I find this odd; surely that shouldn't happen.

Yes. This is just like it did from 98 to 03, 03 to 11 and like it will be from 14 to 17. Don't worry, the standards team hates backwards incompatibility so they try really hard to minimize these differences. But here's a notorious case to the contrary [1].

[1] http://stackoverflow.com/a/620402/489590

I think "subtle differences" should read "subtle improvements" above. No nightmares to be expected :)

You have a point. Some people still write C++03 code because "My code will mostly work fine when I flip flag to C++11 anyway". But I always hope newer standards prevail, and make C++ great again.

And the people who program most of the stuff you can touch with your hands mostly still write c++-kinda-98 because "My compiler doesn't have a flag to flip to C++11 anyway" :(

Off-topic (apologies):

From Xcode, I have the choice between "-std=c++14" and "-std=gnu++14" and I am not sure which I should choose ...

Use "-std=c++14" unless you need the gnu extensions for it to build, that ensures that you don't accidentally introduce non-portable code.

Do you want GNU extensions? Use the latter. Otherwise, use the former.

Gnu++14. This is because historically GCC / clang used gnu++03, so some libraries might require it.

The gnu bit means "add as small number of extensions". None of them are that strange.

Personally, I am really looking forward to constexpr if, i.e. if branches which are discarded at compile time and only have to be syntactically but not semantically correct. This should help a lot in avoiding enable_if magic to select the correct template.

Reply on news.ycombinator.com