C++17 Standard Published | Hacker News Reader

C++17 Standard Published

iso.org

233 pointswhack81 comments

This summary has been helpful for me:

C++17 https://github.com/AnthonyCalandra/modern-cpp-features/blob/...

17/14/11 https://github.com/AnthonyCalandra/modern-cpp-features

I can't even imagine the amount of work that goes into producing a specification like this, BUT... I wish there were a reduced price option for individuals. I just can't justify spending USD 200 on getting a copy for myself. I'd love to have a copy so I don't have to rely on second-hand sources like websites and implementation details from STL maintainers on Reddit or Stack Overflow.

You can build the pdf yourself from the LaTeX source: https://github.com/cplusplus/draft

Or get the latest public draft from https://wg21.link/standard

Or an html version: http://eelis.net/c++draft/

Thanks. I just like having an official (not draft) copy. I'm a nerd.

I just built from the LaTeX source and it's 32 pages longer than the public draft in the second link from 6 weeks ago. Maybe just additional descriptive language, but...

Reading https://github.com/cplusplus/draft, it seems you had to generate figures from their dot source.

If so, the result may depend on your installation (probably even if you use the same version of GraphViz but a different OS and/or set of fonts), and that can affect pagination.

Also, are you sure you built for the same paper size? A4 vs US letter could explain the difference.

Well, you can see changes as recently as two days ago.

https://github.com/cplusplus/draft/commit/83e302d3bb6a5f8855...

In one way, the last draft is more canonical than the official spec - if you are talking chapter and verse to another person about the spec, odds are good that they are referring to the last public draft also.

The C++ draft and published standard are so similar, the only parties I imagine would need the published copy are gcc frontend developers, technical managers at IBM, etc. As an individual who gets into the deep dark crevices of C++, I've never needed the tiny details the published standard offers. They are mostly typographical.

iirc even gcc devs don't have it and use the draft

The reduced price option for individuals is that you just look at the last working draft, which is always published for free for all ISO standards and is almost equivalent to the final product.

The only reason anyone cares about the officially published standard is if you're a compiler vendor who wants to know for sure that your product is standards compliant, which is why the cost for the no-draft versions is what it is.

The almost equivalent is always the scary part. Is there a guarantee that there is no technical difference between the draft and final standard? From your reply, it seems, it is intentionally not specified what exactly are the differences to force compiler vendor to buy the standards. But then the one using a draft is always scared there is one thing different which he has not looked into and this is causing problems somehow.

Non-editorial changes would have to be voted in. This is not an easy process which can happen late.

And mind: It's not only for compiler vendors. An ISO standard is a legal document. Based on your country you might put in your software's contract that your code is compliant C++ code or might consult the standard in a legal debate with a commercial vendor. All quite limited ... but not only compiler vendors.

When C++11 came out, I bought the ANSI copy (identical to the ISO one except for the front page if I remember correctly) for $30. It sure beat the ISO version in terms of price.

You can probably build the drafts from the github repo: https://github.com/cplusplus/draft/tree/c++17

Do any of the standard's people read HN, or is there a way of submitting requests? The STL could seriously use some improvements. std::string doesn't do most of the stuff you want with a string; updating it to an interface like Python's string would be nice. Having a std::vector::append() would be really nice, so I don't have to remember that C++ uses something completely different from every other language. Convenience things like std::set::contains() would be nice because s.find() != s.end() is not very readable compared to contains().

I'm really impressed at what the standards committee has done, but I'm wondering if we ought to start thinking about a C++2.0 where we can write the C++ that we've learned we want. The poor young-uns learning C++ still have to learn all the old stuff, because otherwise it will bite them sooner or later.

Some do. More are active on Reddit. But new proposals can come from anyone. Though, before writing and submitting any, check on the public std-proposals mailinglist if your idea would get any traction. See https://isocpp.org/std/submit-a-proposal

std::set does have a contains() function, it's called count(): http://en.cppreference.com/w/cpp/container/set/count

> The STL could seriously use some improvements. std::string doesn't do most of the stuff you want with a string

std::string predates the STL and most of unicodes history. It was supposed to a be an alternative for using C functions for manipulating NTBS's, nothing more. Since then we've only really had 3 standard revisions, and most languages that see constant evolution still haven't got unicode right...

> Having a std::vector::append() would be really nice, so I don't have to remember that C++ uses something completely different from every other language

I can think of a bunch of languages that don't use "append" for pushing on to the back of a dynamic array. JavaScript for instance, which uses "push"

> I'm wondering if we ought to start thinking about a C++2.0 where we can write the C++ that we've learned we want.

The Ranges proposal/TS goes quite far in this direction. See Eric Nieblers range-v3 library as a testing ground.

Some of us do. There is currently a group of committee members working on text handling. See http://wg21.link/p0244 and https://github.com/tzlaine/text for some future work in that direction.

Why Python string class? The Python 2 one or the Python 3 one? ;-)

String classes are fickle things. It's very hard to get them right. Still, std::string, for all of its age, does let you do a lot of what Python does with manipulation of bytes, particularly when combined with locales (admittedly painful to use) and iostreams (also a bit painful at times).

Python does have a LOT of other functionality tied into strings, but there's a legit design question as to whether that's really a good idea or not. What particular functionality do you think ought to be there?

Python only because it's the string class that I've used that always has everything I need. QString from Qt is pretty good, too. std::string is, like you say, painful. Since QString exists, works great with a long history, so why is std::string so limited? Design-wise, I'd say the few changes which QString has had demonstrates the solidity of the design.

Off the top of my head, what I use frequently (and which is unavailable in std::String) is:

- replace(search, new). std::string can do it, but first you have to find the index of the start, then you call replace() to replace a set of bytes. Too low level.

- endswith() and beginswith() are surprisingly helpful. endswith() in particular. s.index("prefix") == 0 is pretty clear, but s.index("suffix") == s.size() - "suffix".size() is not very clear.

- toupper()/tolower()/isspace()/isslanum()/isupper()/etc. are not something you use every day, but you really don't want to have to write proper handling of every language's idiosyncracies yourself, and it's not worth it to find a library, so probably only European languages will work initially.

- proper unicode handling. std::wstring (UTF16) is not it (to be fair, that wasn't clear at the time of design), plus I don't think it works well with either Microsoft's or Apple's UTF16

- making a string from a number. QString does this well, Python 2's str(num) is not really flexible enough. I don't want to have to create a stringstream just because I need a numeric string.

- create a string from a printf list. I know stringstream is supposed to do that, but I never seem to be able to do exactly what I want (e.g. %.3f), and regardless, I never can remember the correct syntax for the modifiers (e.g. hex(), precision()), despite it appearing like it ought to be obvious.

I pretty much expect all the above in a string. std::string is basically a veneer over an array of bytes. Maybe that was okay in 1998 when it was designed, but the first thing I have to do is add all that in now, every time I do anything UI-related with text.

I also would like split(), it makes simple parsing a lot easier.

> std::set::contains()

I live in a "fast languages only when necessary, and with restraint" shop. Our C++ is not idiomatic, it is meant for programmers from other languages. Anything with iterators is a bit sketchy. It tends to look more like C than C++, and now that I'm an old person I am perfectly happy with that.

We use `s.count(i) == 1`. It's ok -- clear, readable etc. Doesn't give you an iterator if you want to delete the thing too, but most of the time you don't.

Oooph, I'm no expert but that is not "good" C++ style. Definitely prefer using the iterator methods.

If it effectively solves your particular problems in your specific situation, then it IS good style ;)

This depends on knowing the intervals of that type and expecting them to not change.

Just trying to help. This code is entirely implementation specific.

> I'm wondering if we ought to start thinking about a C++2.0 where we can write the C++ that we've learned we want.

Wasn't that the incentive behind the D language?

Well, since D is garbage collected, it really exists in a different world from C++, so I'd say that no, it is not qualified to be in the running for a C++ 2.0.

D's GC can be turned off

I don't use D myself, but I'm curious how often someone actually does that. Is it about the same as how C++ can technically be connected with a GC? Because no one does that, despite that it is possible.

The process for proposals is at https://isocpp.org/std/submit-a-proposal

> but I'm wondering if we ought to start thinking about a C++2.0 where we can write the C++ that we've learned we want

or... you could just use any of the dozens of libraries that already has the API you want (append, contains... they are all in Qt for instance). Why wait for it to standardize ? it's already here and you can use it.

Seems like the meta-language (compile-time expressions) is now pretty much full fledged.

Long gone days where template meta-programming was the only way to do compile-time code generation and constant checks.... at least that's my impression of the latest language-level features.

I have not worked professionally with c++ for a few years now, but his piece from the article, just seems rather powerful incarnation of the compile-time programming.

  constexpr auto add = [] (int x, int y) {
    auto L = [=] { return x; };
    auto R = [=] { return y; };
    return [=] { return L() + R(); };
  };

Can you explain what your code example would be used for (instead of just plus)?

Bah what an horror. I doubt anyone can spot a more unreadable language (except maybe brainfuck).

One of the issues I have with C++ is that they seem to have used basically all the symbols you can find on a keyboard to create unspellable operators or modifiers, and since they didn't have enough to avoid colliding with C, they mixed them to create even more unreadable combinations. The other examples in the doc are good readings as well suggesting I never approach this "modern art".

I think the reason is that adding new keywords to the language always means the risk of breaking somebody's code.

I can see why a standardization body would want to avoid that, even though I agree wholeheartedly the result is not pretty.

> basically all the symbols you can find on a keyboard

C++ doesn't even use @ and $, yet ;)

The way coroutines are implemented in C++17 is just beautiful. Minimal language changes, compatible down to C function pointers and void*, and extensible to almost any existing asynchronous library via trait specialisation.

Didn’t coroutines get pushed out to at least c++20?

Yeah, technically it's a TS, but it's live in MSVC 2015/17 and Clang 5.0

There are no coroutines in C++17. Also not included: modules and concepts.

C++17 is a slight disappointment, I hope C++20 will be the real deal - concepts could really be a game changer and move semantics needs more fixes :/.

It's not as major of an update as previous releases, but there are a lot of little convenience features.

String views, same-line nested namespaces, [[fallthrough]], if with init (I'm sure Google single-handedly got this included; it's very Go-reminiscent and really nice when not using exceptions), structured bindings, maybes with std::optional (occasionally useful), and even just something as simple as emplace returning a reference.

What fixes do you think std::move needs, out of curiosity?

Its not std::move, but the complexity coming with it. Its a hassle applying move semantics correctly and there is not the one goto solution for simple things. Im not aware of a proposal to change that issue, but at least there should be better defaults.

This talk explains the pain quite well: https://www.youtube.com/watch?v=PNRju6_yn3o

The amount of prayer I have put into RVO and moves happening "right"... As someone who isn't a C++ programmer, is there anything better than looking at annotated asm? Templating everything and trying it with something that isn't copyable? (Actually, would that even work with RVO?)

> As someone who isn't a C++ programmer, is there anything better than looking at annotated asm

put a debug breakpoint in the move constructor and run your tests :p

std::move should extend the lifetime of a temporary like static_cast does. (Or else not accept temporaries). Otherwise, no new features necessary. But that one bites sometimes.

D has had concepts for quite a while. They call them template constraints:

https://dlang.org/concepts.html

You should give D metaprogramming a try. It's a whole new world, a new fantastic point of view.

D is in a tough situation right now

I think its good all around and balanced languages, but, there is always a better language for any use case, where D is an alternative

Ocaml, if you want performance close to C/C++ plus and high level abstractions

Rust, if you want manual memory managment

C# and Java, if you want large ecosystems and advanced features

Also C++ is now moving and improving fast Even Ada is sort of making a come back

I'm curious about the Ada comeback - do you have any examples? I know it is still used in space & defense, but I thought those were legacy code bases.

Well, I would recommend you search for Spark, and check the website of AdaCore

But, I would suggest that investing in Rust might be more valuable for one's career I am learning a bit of ADA, only for educational purposes and to scratch an itch, it is very different from anything I used, and I like that

I'd argue D is better than all of those in some ways.

D development is lively and active. I enjoy the language, and I plan to keep using it as long as I keep enjoying it.

That looks really interesting. Is this all done at compile time or runtime? After further reading the answer seems to be compile.

Definitely compile time. D has a somewhat similar feature called contracts (https://dlang.org/spec/contracts.html) which happen at runtime, but don't influence function/template resolution.

For me, the parallelism TS is the Big F*ing Deal: http://www.bfilipek.com/2017/08/cpp17-details-parallel.html

It still is pretty sweet for polyglot developers.

How so?

There aren't a lot of languages that combine functional programming/generics & OO together quite so extensively. There's a lot of power you can unlock there if you can just manage the cognitive load of the syntax.

I really like how D combines these two. The functional programming tools are a lot easier to use than C++ and a lot more practical than Haskell or OCaml. I absolutely adore the idea of purity in D: no side effects. That's all it should be, really. What this means is that it allows you to write pure functions in dirty, imperative ways as long as all the mutation is confined to the function and doesn't leak out.

I really like it.

D is a very nice language, just needs a better GC implementation and more community love.

D is, in a lot of ways, C++ without the syntactical compatibility with C.

Absolutely agreed.

D is kind of the C++ I always wanted. It's familiar, I can see the C++ lineage, and it's so much nicer to write than C++.

I'm currently having fun writing Advent of Code in D:

http://inversethought.com/hg/aoc/file/tip/2017

On my case, C++ only gets used to do low level stuff as library to integrate into Java and .NET applications.

So modules and concepts were nice to have, but C++17 is already a very good improvement to write such kind of libraries.

What are concepts? Is it like java/golang interfaces or rust traits?

It’s sorta like traits but also different.

Can someone kindly post links or books for a beginner to dive into learning C++? It is a bit intimidating to approach fresh.

I'd recommend to choose one of these two books:

Programming: Principles and Practice Using C++, 2nd Ed., Bjarne Stroustrup https://www.amazon.com/Programming-Principles-Practice-Using...

C++ Primer, 5th Ed., Stanley Lippman https://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/03217...

For a very brief introduction:

A Tour of C++, Bjarne Stroustrup https://www.amazon.com/Tour-C-Depth/dp/0321958314/ref=sr_1_1...

Here's more info regarding book recs: https://isocpp.org/wiki/faq/how-to-learn-cpp#best-book

Awesome news. Long live C++ ;)

Awesome news. gcc has had experimental support for C++17 for a while now, any idea on a potential time frame for it to move from experimental to final standards compliant?

Really, UTF literals only now?

Nope. They just got a minor update.

Are my eyes failing me?

> C++17 includes the following new language features:

> ...

> utf-8 character literals

> ...

> char x = u8'x';

C++11 introduced utf-8 encoded string literals. However, when the parser was reading the characters in the literal, they were interpreted in whatever character set encoding the compiler was using (you could use escaped characters to represent unicode characters that had no representation in that encoding).

Do I really have to pay for a pdf of the standard? (sorry I just don't see anyway else to download the pdf)

Yep. You can download the latest working draft from open-std.org though: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n470...

Just go to https://github.com/cplusplus/draft for drafts. Choose a draft version that is produced right before the actual date of standardization and there are only very minor differences between the draft and the real deal.

Yes, I should emphasize that the minor differences are really minor and mostly typographical. There's no reason to need the published copy over the draft unless you're IBM working on icc, one of the head gcc maintainers, etc.

Someone will upload it on libgen within a few days

That is illegal.

cool story

and?

maybe he's a lawman

Reply on news.ycombinator.com