
C++ 17 is Done - eklavyaa
https://herbsutter.com/2017/03/24/trip-report-winter-iso-c-standards-meeting-kona-c17-is-complete/
======
asitdhal
For those who wants to know c++17 features

[http://stackoverflow.com/questions/38060436/what-are-the-
new...](http://stackoverflow.com/questions/38060436/what-are-the-new-features-
in-c17)

std::optional and std::any are one of the good things. std::apply and
std::invoke can help you write better functional c++17 code.

Anyway thanks for C++17. For sometime, I thought I will learn Rust.

~~~
tmyklebu
In modern gcc, std::variant doesn't look like a competent replacement for old-
fashioned tagged unions.

On x86_64 Linux, it looks like a function with signature `void
f(std::variant<int, char>)` expects its (8-byte) argument to be passed by
reference, whereas `void f2(tagged_union_of_int_and_char)` passes its argument
in rdi.

gcc (-O3) also generates miserable code for calling f(42):

    
    
      4004f0:       48 83 ec 18             sub    $0x18,%rsp
      4004f4:       48 89 e7                mov    %rsp,%rdi
      4004f7:       c7 04 24 2a 00 00 00    movl   $0x2a,(%rsp)
      4004fe:       c6 44 24 04 00          movb   $0x0,0x4(%rsp)
      400503:       e8 c8 ff ff ff          callq  4004d0 <f>
      400508:       48 83 c4 18             add    $0x18,%rsp
      40050c:       c3                      retq
    

as compared with calling f2(42):

    
    
      400510:       48 bf 00 00 00 00 2a    movabs $0x2a00000000,%rdi
      400517:       00 00 00
      40051a:       eb c4                   jmp    4004e0 <f2>
    

std::optional seems to have the same disease; the ABI is different from a
plain struct containing a bool and the value and you get worse initialisation
code. There's also a build time penalty to using std::optional; on my machine,
including the code that uses optionals makes my trivial test program take
320ms to compile and link rather than 50ms.

These look like yet more new C++ features that are worse than what they're
trying to replace.

~~~
typon
Does anyone know what kind of assembly is generated when using std::option in
Rust when make a similar function call?

~~~
steveklabnik

      void f(std::variant<int, char>)
    

would be

    
    
      f(x: IntOrChar)
    

roughly in Rust, I'm too lazy to make the types _exactly_ the same, but
[https://godbolt.org/g/pZde2A](https://godbolt.org/g/pZde2A) is roughly it.

Actually, [https://godbolt.org/g/1vcMeG](https://godbolt.org/g/1vcMeG) might
be even better to compare; I'm not an expert, but looks like the only
difference is in the size.

last one, adding inline(never) so you can see the calls in main:
[https://godbolt.org/g/cVDjQH](https://godbolt.org/g/cVDjQH)

    
    
      movabs  rdi, 21474836480
      call    example::f1@PLT
    

vs

    
    
      mov     edi, 5
      pop     rbp
      jmp     example::f2@PLT
    

so, yup.

~~~
typon
Thank you! This is really cool.

------
jug
Boy... Would be a nice time to learn C++ again.

I mean modern C++, with all lessons learned, all revisions thus far assumed to
be supported, officially and unofficially deprecated coding styles marked in
helpful tidy little "Don't do this and this is why!" red warning boxes. Bjarne
Stroustrup himself said C++11... _11_ almost felt like a new language, and
here we are already!

C++ is so big, and not only that, changing so much. I have a hard time
catching up and a distilled "sum of knowledge" C++ programming language guide
would be immensely helpful. C++17 including all its predecessors almost feel
more like D at this point, soon enough only missing GC compared to that, which
by itself have alternatives in modern C++ that some argue is even better.

I also think there's a disconnect in how people perceive C++ today. Many seem
to think of an archaic language, Quora questions "Are C++ worthwile to learn
today?" abound... Another argument for a high visibility language guide being
useful?

Documents like these are helpful but not very easy to digest:
[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md)

------
systems
As a matter of personal taste, I prefer big complex languages over simple ones

And I do consider, that some of the strongest criticism of C++, and that is,
"that most people use a subset of it, so it feels like many different
languages glued into one", is actually a strength .. it means you can ignore
some the complexity .. until you want it, or need it

I am very happy, that C++ is adding new features every 3 years .. and I do
plan to invest more time in C++

Complexity is good

~~~
fauigerzigerk
Nothing against personal preferences, but one side-effect of overwhelming
complexity is that only very few people can be trusted to write safe C++. The
better you know C++ the more suspicious you become of C++ code written by
others. At least that is my personal experience.

And I think that's a major reason why C++ usage is gradually becoming a niche
thing used only where absolutely necessary. As evidence for that claim I
submit this chart (you need to scroll down a page):
[https://www.itjobswatch.co.uk/jobs/uk/c++.do](https://www.itjobswatch.co.uk/jobs/uk/c++.do)

C++ used to be required for over 30% of all permanent programming jobs in the
UK back in 2005. Now it's down to 8.5% and falling. That's in stark contrast
with all the enthusiasm created by the features added since C++11, features
that I very much welcome.

~~~
overgard
C++ has been getting a lot safer though. Modern C++ generally has you using
shared_ptr and unique_ptr and references, which cut down on a lot of common
pointer mistakes. There's also a lot of const mixed in, which I think helps.
Debuggers have also gotten a lot more reliable (I remember one crash bug that
I couldn't find after like three days of looking in an old visual studio
version, whereas newer visual studio caught it immediately). Not that the
language isn't a minefield, but if you walk in the modern part there's a lot
less mines buried in the ground.

As much as I complain about C++, I just don't think there's a viable
alternative, and I somewhat reject the notion that writing performant code is
a niche thing. Like, sure, there are common contexts where you can get away
with wasting CPU, but IMO part of being a skilled professional programmer is
getting the most out of the machine, and you just can't do that with most
other languages.

~~~
progman
> I just don't think there's a viable alternative

If C++ is your only hammer then every problem looks like a nail to you. Of
course, there are viable alternatives. At least Ada which is still used in
avionics and other safety critical systems.

~~~
imron
> At least Ada which is still used in avionics and other safety critical
> systems.

Like Ariane 5? :->

The crash was caused in part by failing to catch an exception in Ada.

[http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html](http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html)

~~~
progman
This was not Ada's fault but the developer team's fault since it used a
working Ariane 4 software for Ariane 5 without exhaustive testing. They made
the mistake, and blamed Ada for that. The Ada software worked perfectly for
which it was written for.

[http://compgroups.net/comp.lang.ada/ariane5-faq/1406823](http://compgroups.net/comp.lang.ada/ariane5-faq/1406823)

And yes, Ada is still used today.

[http://www.ada2012.org](http://www.ada2012.org)

~~~
imron
So how many crashes that happen in programs written in C++ are the development
teams fault rather than the C++'s?

Ada is an interesting language (we were taught it as our first language at
uni), but it's not free from safety issues.

~~~
progman
Crashes due to the language implementation's fault are much more likely in C++
than in Ada. Ada compilers are 100% verified, otherwise they are not allowed
to call themselves "Ada compiler". There is no such thing for C++. The safety
gap between C++ and Ada is actually so big that we don't even need to talk
about that.

The flaws C++ were the reasons why Rust was invented. Mozilla wanted a safe
language for the next generation of browsers, and they realized that C++ is
not a good choice for safe programming.

Quote: "Mozilla intends to use Rust as a platform for prototyping experimental
browser architectures. Specifically, the hope is to develop a browser that is
more amenable to parallelization than existing ones, while also being less
prone to common C++ coding errors."

Source: [https://www.quora.com/Why-is-Mozilla-developing-the-Rust-
lan...](https://www.quora.com/Why-is-Mozilla-developing-the-Rust-language-and-
what-are-the-problem-areas-for-which-it-is-better-suited-than-conventional-
languages-How-does-it-compare-to-other-system-languages)

------
codebeaker
Every time there's something that comes up for C++ I get excited, I've always
wanted to use the language, but it's like tap dancing in a mine field.

C++ needs a linter that rejects code that doesn't meet a certain standard ala
Rubocop.

~~~
dahart
?? Compilers do reject code that doesn't meet a certain standard. C++ does
come with a "linter". You might want to check out what -Wall does in gcc &
clang.

I've never met a linter I liked more than a real compiler, not even close.
Linters for scripting languages only exist because the scripting languages
aren't compiled, and they are only lightweight second rate optional type
checkers. Linters' attraction and usefulness is that you aren't required to
use them, so you can iterate quickly and run code without having to wait for
the compiler every single time you save your file. Linters are not better at
keeping you within good style and safety bounds, generally speaking.

~~~
rleigh
This is way too low a bar. I already use this plus:

    
    
        -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 -Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long -Wnon-virtual-dtor -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros -Wno-unused-local-typedef -Wno-language-extension-token -fstrict-aliasing
    

and optionally:

    
    
        -Wconversion -Wdocumentation -Wfloat-equal -Wmissing-prototypes -Wold-style-cast -Wunreachable-code
    

and this is still insufficient. Why? Because this is only checking syntactical
and semantic correctness. It can't check for violation of local policy, such
as:

no use of new/delete (use make_unique or make_shared)

correct and consistent use of virtual inheritance across the entire codebase

rule of three and rule of five usage

etc.

These are mostly higher-level concerns. Stuff which other people on my team
might introduce, and/or miss in review.

I don't yet have anything automated in place for this, but clang-tidy is on my
todo list for investigation.

~~~
dahart
So, then you feel that @codebeaker should wait to learn C++ until tools that
fulfill your wishlist are available? You agree that C++ is a minefield
compared to Ruby, only because Ruby has Rubocop and C++ doesn't?

Have you used any linters? Because linters are even worse than what you're
describing with the C++ compiler. What they do is complain about style issues
that some people believe are likely to lead to syntactical and semantic
errors, without actually checking for the syntactical and semantic errors like
a compiler does. Linters also don't check for violation of local policy,
unless you extend them yourself. (And feel free to extend clang's warnings to
suit your needs... it is open source.)

I fully 100% completely agree that C++ tooling could be way better, and I wish
it was too. But that's not the issue we're talking about here at all.

------
hsivonen
I’m annoyed that the migration to “byte is uint8_t” from the “is a byte char
or unsigned char?” mess is disrupted with std::byte.

------
pjmlp
Congratulations to everyone involved, pity we still haven't got concepts and
modules into it, but there is still hope for the next round. :)

Until of one the more secure alternatives gets more mainstream adoption, thus
starting to be requested by our customers, C++ is going to be the tool to go
to, when I need to step out of JVM and .NET languages to something more low
level.

~~~
Athas
Is there an overview of what kind of challenges prevent the inclusion of
modules? I don't do much C++ anymore, but I've done a fair bit of work on
module systems, and they've never seemed that complicated to me. (I worry that
the answer will mention the preprocessor...)

~~~
lomnakkus
TL;DR: It has a lot to do with the preprocessor, macros specifically.

------
oblio
Is there any plan, anywhere, to try to provide a standard, modern subset of
C++? Sort of like Perl and Javascript have strict mode.

Something that could be enforced by all the compilers.

~~~
pjmlp
Yes, C++ Core Guidelines.

Many of the suggestions are supported in VC++ and clang-tidy.

Other commercial vendors are slowly adopting them on their linters.

Strangely, gcc seems absent from this effort.

------
faragon
"Perhaps the most exciting thing was that we decided to add the std::byte
type"

So "std::byte" is not a character ("std::char") nor arithmetic
("std::int8_t/uint8_t"), but allows bitwise operations. It was really
necessary? Anyone knows if that type allows defining the byte size in bits per
instance?

~~~
jtsylve
Nope, the spec seems to suggest it's unsigned char. This is also what gcc has
done.
[https://patchwork.ozlabs.org/patch/737032/](https://patchwork.ozlabs.org/patch/737032/)

~~~
fnj
Can anyone express plainly what is the point of the std::byte circle jerk when
we already have uint8_t?

~~~
andreyv
std::uint8_t is not required to exist on a particular implementation, for
example, if the machine byte is not 8-bit.

std::byte still seems pretty useless, though. There already is a built-in type
for designating bytes: unsigned char.

~~~
evanmoran
It's for clarity about fixed size bitwise operations. Here's how the spec doc
describes it's motivation:

([http://open-
std.org/JTC1/SC22/WG21/docs/papers/2017/p0298r3....](http://open-
std.org/JTC1/SC22/WG21/docs/papers/2017/p0298r3.pdf))

Motivation and Scope:

Many programs require byte-oriented access to memory. Today, such programs
must use either the char, signed char, or unsigned char types for this
purpose. However, these types perform a “triple duty”. Not only are they used
for byte addressing, but also as arithmetic types, and as character types.
This multiplicity of roles opens the door for programmer error – such as
accidentally performing arithmetic on memory that should be treated as a byte
value – and confusion for both programmers and tools.

Having a distinct byte type improves type-safety, by distinguishing byte-
oriented access to memory from accessing memory as a character or integral
value. It improves readability. Having the type would also make the intent of
code clearer to readers (as well as tooling for understanding and transforming
programs). It increases type-safety by removing ambiguities in expression of
programmer’s intent, thereby increasing the accuracy of analysis tools.

~~~
userbinator
_such as accidentally performing arithmetic on memory that should be treated
as a byte value_

My reaction to that can be summed up succinctly as "WTF!?" The whole point of
uint8_t or (signed/unsigned) char is an 8-bit quantity that you can do
arithmetic and bitwise operations on. To put it more bluntly, "have C++
programmers forgotten how computers work?"

The proposed solution is to add yet another same-yet-subtly-different type,
with its own set of same-yet-subtly-different rules? If anything that would
cause even more confusion due to the complexity it causes in interactions with
all the other parts of the language.

IMHO this "let's do everything we can to stop people from even the very
slightest change of _possibly_ doing something wrong" line of thinking is
ultimately unproductive... and actually rather dystopian. The end-result is
quite scary to contemplate.

(The fact that an 11-page, text-only PDF somehow turns out to be over 800KB is
somewhat less disturbing, but still notable.)

~~~
SamReidHughes
It's just a bit of type safety. Calm down.

------
Coding_Cat
Still no concepts unfortunately (or reflection). Bit disappointed really, I'm
far from a guru but to me this seems like another 'tick' upgrade where c++11
was a big 'tock', c++14 was mostly polish to c++11.

~~~
wrsh07
If you don't think of it as building a specific version and more just as a
snapshot of what is currently 100% ready-to-go, you'll maybe feel differently.

They did much of the work needed to get modules, concepts, ranges, reflection,
parallelism, etc ready to go, but this snapshot doesn't include them.

Nonetheless, many of those features will be finished soon and may be available
by compilers before c++20

------
mr_overalls
Dumb question: How popular is C++ as a systems programming language in 2017?
Does anyone have data on the popularity of various languages (C, Rust, Go,
etc.) when web and application development are excluded?

~~~
lossolo
C and C++ are the most popular "systems programming languages", C is king in
embedded, kernels, C++ is a king in everything else. Go is not strictly
"systems programming language", as to Rust popularity this is the most
pragmatic answer I've seen lately:

 _"... Let's see Rust for what it is: the latest attempt at a C++ replacement.
These have come and gone over the years, and it's by no means clear that Rust
will succeed. As an example, Rust is currently 43rd of the 50 languages
monitored in the Tiobe index. For comparison with languages of a similar
vintage, Swift and Go are 10th and 17th respectively. C++ is 3rd. To put it
bluntly: almost nobody is using Rust in the real world yet.

So please, ease up on the hype, Rust users. Have a little humility. You've got
a nice little language with some really good ideas, and having a static
analyser built into your compiler is cool. But there's a long way to go
yet."_[1]

[1]
[https://www.reddit.com/r/cpp/comments/611811/have_you_used_r...](https://www.reddit.com/r/cpp/comments/611811/have_you_used_rust_do_you_prefer_it_over_modern_c/dfb924w/)

~~~
abiox
i recall there being some whining over go and "systems programming", but this
seemed to hinge on definitions. go may not be the right option for a kernel
but it's great for servers, infrastructure, platforms and various related
things.

~~~
tmccrmck
Systems programming is a vague term but it usually refers to low latency
software (e.g. kernels, browsers, OS's, embedded, databases, etc) which means
anything with a garbage collector is out of the question.

~~~
abiox
that's just the thing: "anything with a garbage collector is out of the
question" seems limited to a particular camp.

------
kensai
Lovely! But the real champagne opener is when certain mainstream compilers
completely support all features.

PS. Please don't forget to show some love for C2x now. :D

~~~
shakna
GCC [0] is pretty much done.

Clang [1] needs a couple more things.

MSVC [2] hasn't done as much, but shouldn't be too far away. [3].

Considering how long C++11 took before it was fully implemented, this seems so
fast!

[0] [https://gcc.gnu.org/projects/cxx-
status.html#cxx1z](https://gcc.gnu.org/projects/cxx-status.html#cxx1z)

[1]
[http://clang.llvm.org/cxx_status.html](http://clang.llvm.org/cxx_status.html)

[2] [https://msdn.microsoft.com/en-
us/library/hh567368.aspx](https://msdn.microsoft.com/en-
us/library/hh567368.aspx)

[3]
[https://blogs.msdn.microsoft.com/vcblog/2016/01/22/vs-2015-u...](https://blogs.msdn.microsoft.com/vcblog/2016/01/22/vs-2015-update-2s-stl-
is-c17-so-far-feature-complete/)

------
gigatexal
I'm just glad to see languages as old* as C++ evolve and continue to have
improvements made. It's a good time to be a programmer: our tools just keep
getting better.

*Old but close to metal and fast and versatile.

------
lukaszjb
I feel like we need some c+ not c++...

~~~
fauigerzigerk
I agree. C + RAII.

~~~
DSMan195276
If that's all you want, you might take a look at the `cleanup` attribute for
C. It's non-standard, but it is supported by `gcc` and `clang` and is fairly
effective.

------
faragon
C++ is becoming Java.

~~~
Koshkin
This is one of the nicer things one could say about C++. Indeed, it is
possible now to write C++ almost as if it was Java and still produce a
reasonably efficient code!

~~~
faragon
Sure. That was my point, no pun intended.

------
wmu
It's too late for C++ to regain popularity. C++17 features will become
widespread in next 3-4 years (C++14 isn't a common standard yet). Moreover,
the language has become incredibly complicated and sadly doesn't provide
anything that would reflect modern needs.

~~~
jeremyjh
First, all the compilers already implement pretty much all of it. I'm not sure
if by widespread you mean "included in a distribution" but you can use these
features today, if you want to install a compiler.

Second, C++ is popular by pretty much every measure I could think of. Whether
you want to measure lines of code, or number of projects, or number of
developers - it is very high on the list.

It is true that is not popular with web developers and gets shouted down in
those echo chambers, but the web entirely runs on C++ because all browsers are
written in C++.

~~~
wmu
> First, all the compilers already implement pretty much all of it. I'm not
> sure if by widespread you mean "included in a distribution" but you can use
> these features today, if you want to install a compiler.

Of course, I can install any compiler, but my employer might not allow me to
use it. Porting to a new compiler is not an easy task when a code base is
large; we postponed porting due to lack of time.

> Second, C++ is popular by pretty much every measure I could think of.
> Whether you want to measure lines of code, or number of projects, or number
> of developers - it is very high on the list.

More interesting measure would be the number of new projects.

> It is true that is not popular with web developers and gets shouted down in
> those echo chambers, but the web entirely runs on C++ because all browsers
> are written in C++.

In web backend C++ is not used. You find there C#, Java, PHP, Python, maybe
Go.

~~~
fnj
If you have to "port" your code from one C++ compiler to a new C++ compiler,
then they are not both true C++ compilers per standards, or your code is not
pure standard C++.

~~~
wmu
Sometimes compilers have bugs or are not fully-compliant. For example MSVC two
or three versions ago didn't understand =delete. Standard library also might
have errors. Moreover, we use third-part libs that are not always up to date
(for various reasons), we have some legacy parts, and so on and so forth. I
wish switching compiler required only setting another CXX. :)

