
C++20 has been approved - dgellow
https://twitter.com/PatriceRoy1/status/1302055575140945921
======
hackingthenews
Even as a C++ programmer with too much spare time, it has become obvious that
learning and using all of C++ is beyond impractical. To the point where I find
that my C++ code more than ever before looks like C.

Nowadays I am using C++ mainly for the high-performance libraries, and only if
I can't archive the same in jit-ed python, cython or rust.

The Java strategy of being very conservative about what you add to the
frontend would have done C++ a lot of good after C++11 (or even before that).

~~~
rubber_duck
>The Java strategy of being very conservative about what you add to the
frontend would have done C++ a lot of good after C++11 (or even before that).

Java lost a lot of mindshare to C# and Kotlin due to that "strategy".

~~~
cletus
So C# definitely benefited with the second mover advantage. It learned a bunch
of lessons from Java such as:

\- No checked exceptions

\- Properties (I wish Java would add this to the core language instead of
relying on things like Lombok as it shouldn't change the IR and really is just
syntactic sugar)

\- Partial classes. This really isn't in contrast to Java because Java has
nothing like it. But it is a neat feature for partial code generation;

\- LINQ. Java eventually added streams but last I checked it still had
performance issues and IMHO LINQ is just cleaner;

\- Conditional compilation. This is really a huge oversight. One of the huge
benefits of the preprocessor in C/C++ was conditional compilation. It's great
than C# included it. It's bizarre to me that Java hasn't.

\- Async/await. Honestly I still find C#'s version of this more awkward than
Hack's. Experience has taught me that whenever you spawn a thread, you've
probably made a mistake as subtle mutlithreading bugs are the devil and
cooperative multitasking like you have in Go, C# and Hack is usually far safer
and sufficient most of the time. Still, C# is still better than Java here.

\- C#'s reified generics vs Java's type erasure. I think it was the right
decision to break backwards compatibility here (and I don't usually say this).
This was pretty early too (IIRC generics were added in C# 2.0).

But all that being said, I still think Java has a large mindshare and install
base than C# by a mile. it's not sexy so it gets less attention on HN but Java
is still massive.

As for Kotlin? Much like Scala I see this as nothing more than a curiosity.
Android developers seem to like it but I think it's a tiny fraction of Java
still.

~~~
bcrosby95
LINQ is cleaner, but I find streams to be more elegant when considering the
language as a whole (its just a pure library - no new syntax/rules/etc to
learn).

I feel like a lot of languages these days trend towards "kitchen sink"
languages that toss in everything and the kitchen sink in the name of clean
looking code. IMHO this tends to sacrifice language elegance. This is probably
why I tend to like languages like Java/Go/Clojure.

~~~
thelazydogsback
There is not new syntax for LINQ either -- it's just fluent-style via
extension methods. I don't know many people that use the SQL-like syntax any
more -- and it only covers a tiny amount of the functionality.

------
dgellow
Has anyone anything positive to say about C++, and more specifically C++20?

We all know the negative parts, any C++ related thread is always full of
people repeating them over and over. What about some celebration time for now?
A huge milestone for the language has been reached with C++20, can we share
something positive about it for once?

~~~
AlexSW
As someone that really likes C++ templates (no other language seems to come
close in power for such a compile-time typed system), I'm particularly looking
forward to concepts, and I believe (correct me if I'm wrong) that they will
make compiler errors for templated code much more straightforward, which will
be a nice quality of life improvement even if not using concepts directly.

~~~
greggman3
That strikes me as Stockholm Syndrome. No one in their right mind would
consider C++ templates a good design for a meta-language. In fact the majority
of older template patterns aren't based on good language design but hacks
around conditional compiling via arrays of size -1 and crap like that.

A good meta programming language would be one that's as easy to program as a
general language. lisp, nim, etc...

~~~
_se
I think this is.. quite wrong. I don't think C++ is an amazing language (it's
not in my top 3 personally, but I do work with it daily), but templates are
one of the best things about the language IMO.

I have a lot of experience with many different types of metaprogramming (cl
macros, Rust macros, template Haskell (and Typeable/Generic), ... even CLR
code generation) and C++ templates are better than everything I've used other
than Common Lisp once you really understand them. A really common C++ theme I
see is people that don't understand things railing against them (I used to be
in this camp myself, so I can identify with the sentiment).

Templates allow you to choose at will between nominal/structural subtyping (in
a way), perform type-level logic, generate code that can be thread-safe or
lock-free at the caller's whim... They are very powerful, much more than most
devs realize, and if you understand C++, writing them is not difficult.

The "really understand them" part is, of course, the hard part. You need to
understand the core language and the template language to be effective with
them. I can see why even some experienced C++ developers shy away from
templates.

~~~
Dylan16807
Even if they're a good general design, half the uses of SFINAE are absolutely
insane and from what I understand it's significantly harder than it should be
to make a fully generic template across all kinds of edge case and corner case
types.

The attitude with templates seems to be that if something is at all possible
with hacks then there doesn't need to be any language support added, even if
it would be vastly simpler to read and write and probably to compile. I don't
think that works out well.

~~~
northwindfoo
I wouldn't call myself a c++ expert but I have used the language for a long
time. In my opinion, templates have a lot of awesome uses outside of SFINAE
and if you find yourself reaching for SFINAE, that's probably code smell and
you can probably simplify the design elsewhere to avoid it.

Generally I find the best use of templates is the most basic: you want to
write some code that operates on duck-types. As long as one is able to control
themselves and pick the right use cases for maintainability, templates are
simple enough. In my experience, this is very doable.

Concepts are also a really cool way to rein in which types are accepted as a
template parameter and have a lot of potential to make templates easier to
understand and teach. To me, this is the most exciting c++20 feature.

------
linkdd
Finally concepts !

But the module spec feels a bit weird (
[https://isocpp.org/files/papers/n4720.pdf](https://isocpp.org/files/papers/n4720.pdf)
).

I mean, "import M" should create a M namespace with the imported symbols.
Here, it's more like "from M import *" in Python.

~~~
HelloNurse
Python collapses the name of the module (usually the name of a file) and the
name of the "namespace" on the importing side, while C++ modules add a level
of indirection by specifying arbitrary namespaces for module content
(independent of the name of the module).

Evidently, the complexity of finding the same namespace in multiple
compilation units has been considered acceptable for C++ modules because it
was already handled decently.

------
beagle3
I've left C++ for C (and Python, and K, and others) somewhere around 2007 when
it only started getting crazy. I sort-of keep track of the changes to the
standard like lambdas, without which you can't read modern code.

But assuming I lose my sanity again and decide to go back to doing C++, which
resource would you recommend for properly catching up the last 15 years of C++
changes?

~~~
nikki93
Tour of C++ by Bjarne Stroustrup as others have mentioned.

Effective Modern C++ by Scott Meyers (esp. for the chapters on smart
pointers).

Arthur O' Dwyer's "Mastering the C++17 STL"

David Vandervoode and Nicolai Josuttis etc.'s "Templates the Complete Guide"

The first chapter of "Elements of Programming" by Stepanov, and maybe the rest
if you want.

I think also, just kinda glancing over the spec.

Bjarne's paper on the evolution of C++ from 2006 to 2020 is also important I
think:
[https://dl.acm.org/doi/10.1145/3386320](https://dl.acm.org/doi/10.1145/3386320)

As for talks,
[https://www.youtube.com/watch?v=XS2JddPq7GQ](https://www.youtube.com/watch?v=XS2JddPq7GQ)
is great for value categories and move semantics

[https://www.youtube.com/watch?v=St0MNEU5b0o&t=6s](https://www.youtube.com/watch?v=St0MNEU5b0o&t=6s)
also move semantics, and also part 2 of that if you want

I'll add more talks here in a bit!

And honestly if you've liked C, you can get far by just starting with that
then slowly adding things you want. I think the first things one may end up
reaching for are std::vector / std::string etc.; then being able to attach
methods to types, then some templates, some auto, some lambdas. The old
vtables / RTTI approach I basically never use anymore.

~~~
nikki93
Actually "C++ Crash Course: A Fast-Paced Introduction" by Josh Lospinoso seems
to cover some good ground.

------
melling
There are a lot of changes:

[https://en.wikipedia.org/wiki/C%2B%2B20](https://en.wikipedia.org/wiki/C%2B%2B20)

[https://en.cppreference.com/w/cpp/compiler_support](https://en.cppreference.com/w/cpp/compiler_support)

~~~
The_rationalist
Except for the memory model, rust is loosing a lot of it's competitive
advantages over C++ here and more interestingly: C++ is pushing the frontier
on what new features/optimizations should a high performance language get. I
feel like some of those features will allow new kind of optimizations and it
could have an impact on the performance of everyday programs like chromium or
Firefox. Of course the adoption will take a few years

I really hope that Rust compiler team will investigate in great depth the
expert changes in C++20 and backport the relevant stuff into rust

~~~
beagle3
> Except for the memory model, rust is loosing a lot of it's competitive
> advantages over C++ here

Rust's memory model is by far its most significant advantage over C++, and it
cannot be added to C++ without breaking all backwards compatibility.

~~~
Matthias247
Right. Rust is the only of those languages where I feel comfortable handing
tasks out to junior programmers and NOT having to hunt for memory errors later
in code reviews. That’s such a great reassurance and productivity gain for
everyone that it seems hard to go back.

In addition to that it also protects against the majority of multithreading
issues - which is something not even available in managed languages like C# or
Java.

------
FpUser
>"Even as a C++ programmer with too much spare time, it has become obvious
that learning and using all of C++ is beyond impractical."

Who says on must know and use all the features of a language (especially the
monster like C++) to write good code / software. Check what you really need
for your particular task and be happy. I've found modern C++ a breeze to use
as long as I do not pretend to be a language guru. Writing some sophisticated
STL like libraries is highly specific and involved task and person/s doing
that are not doing much of anything else so they would know all the of
relevant C++. Using those libraries however is way way easier, the code looks
pretty clear.

I use modern C++ to write various business servers. To me it is a single tool
or two with clear and relatively easy subset of a powerful language. When I
compare it with the monstrosity of some standard "modern" back-end
stacks/toolsets C++ is starting to look like a small fish.

~~~
gumby
I don’t know why this was voted down. C++ has a lot of tools for library
writers which are unnecessary when writing application code but make libraries
more adaptable. Also c++ keeps a lot of backward compatible code so old code
continues to run (so there’s less of the Python 2->3 anguish).

English is full of words I don’t use on a daily basis but that doesn’t make it
bad.

(Not picking on python btw, just using a prominent example of an alternative
path)

~~~
FpUser
>"I don’t know why this was voted down"

I suspect it was not because of C++ but me mentioning a monstrosity of some
modern back end stacks. I think people get attached to the way of doing things
and it becomes akin to religion.

------
IshKebab
This fixes so many long-standing annoyances! Modules at last. String literals
as template parameters. Ranges! C99 designated initialisers! Can't wait to be
able to use this in about 5 years :-D

~~~
shash
Looks like most of these features are already supported by the major
compilers. A few might be hiding behind a flag or three but I expect them to
be defaulted soon.

~~~
IshKebab
Right it's probably fine for hobby projects but for commercial projects you
have to wait until it's supported on all platforms and the majority of your
customers are happy with you using it. It can take a long time (e.g.
std::optional was only supported on Mac in 2019ish).

------
algesten
Were the module problems ironed out? I remember reading some scathing
criticism of the early designs.

~~~
summerlight
[https://vector-of-bool.github.io/2019/03/04/modules-
doa-2.ht...](https://vector-of-bool.github.io/2019/03/04/modules-doa-2.html)

The issue was that there's no language level definition of module
implementation and layout so every build system may need to handle every
single module implementation differently. The standard body decided to publish
a technical report on this issue to ensure some level of interoperability
across module implementations.

------
gugagore
I am reminded of this:
[https://www.devever.net/~hl/nexuses](https://www.devever.net/~hl/nexuses)

"[...] because nobody programs in C++ — everyone programs in their own unique
subset of the language. If you are told a program is written in C++, that
leaves the following questions:

Does it use, or eschew, exceptions? Does it use, or eschew, C++ RTTI? Does it
use operator overloading? Does it use, or eschew, the STL? Does it use, or
eschew, C++11/C++14/etc. features? Does it use templates? Does it use virtual
functions? Does it use multiple or virtual inheritance? Does it use static
objects with constructors?"

~~~
b20000
isn't that great? nobody speaks English. we all speak our own subset of the
language.

~~~
lifthrasiir
And yet people in _cough_ some _cough_ countries insist that their English is
The English. Likewise, if we had and used a widespread definition of subsets
of C++ it'd be pretty much okay. Haven't JavaScript gone this way ("good
JavaScript")?

~~~
b20000
how much software in the world is written in C++, vs written in javascript,
and how much of that is actually relevant, in that it contributes something
meaningful to society?

------
frou_dh
Cool that real modules are now official. Preprocessor textual inclusion should
have been left behind in the previous century!

~~~
gmueckl
The preprocessor is not gone. It still exists in the context of modules.
Figuring out the details of that interaction has been a major issue when
defining modules and the result is quite complex.

I doubt that we will see clean modules that are free of preprocessor
shenanigans, especially when writing any non-trivial portable library. I am no
prophet, but I currently assume that unless we get hygienic module friendly
macros and better conditional compilation on a syntactic level than dumb
textual #ifdef, modules will only end up adding complexity in practice.

~~~
gpderetta
The biggest reason that macros are not going away is backward compatibility (a
very important reason of course). Adding hygenic macros or "module friendly"
macros would not help one bit with that.

Also I belive that macros do not escape modules by default. That's a huge
improvement.

------
zelly
I'm looking forward to reflection and executors in 23. Then it will basically
be the most powerful language. With compile-time reflection, you could add
whatever language feature you want--almost as powerful as Common Lisp macros.

------
anonymousse1234
C++ Core Guidelines
[https://github.com/isocpp/CppCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines)

Bjarne Stroustrup: C++ | Lex Fridman Podcast #48
[https://www.youtube.com/watch?v=uTxRF5ag27A](https://www.youtube.com/watch?v=uTxRF5ag27A)

------
andi999
If msvc would support a more modern C, i predict a lot of people would use
this instead of C++. (Thanks Herb)

~~~
flohofwoe
C11 support is on the roadmap since a few weeks ago:

[https://developercommunity.visualstudio.com/idea/387315/add-...](https://developercommunity.visualstudio.com/idea/387315/add-c11-support.html)

I hope this also means the MSVC team had a change of mind regarding this very
unfortunate blog post which IMHO did more damage to C than anything else in
the last 20 years:

[https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-
an...](https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/)

~~~
pjmlp
And rightfully so, C code has no place in modern _secure_ computing besides
UNIX kernel clones, and legacy code.

~~~
flohofwoe
Security should be provided by a sandbox technology. Is it wise to implement
the sandbox in C (or C++, because that really doesn't make a difference)?
Probably not. For most other use cases it's fine to use "unsafe languages".

~~~
pjmlp
Sandoxes don't prevent security exploits due to internal memory corruption of
the sandbox.

~~~
flohofwoe
But bad actors won't use memory-safe languages either ;) The purpose of the
sandbox is to keep the damage contained, no matter if this damage was intended
or not.

~~~
pjmlp
The less memory unsafe languages get used the better, regardless of
sandboxing.

Here C++ has an edge over C, because it offers the language features for
memory safe array and string manipulation, and most C++ compilers do offer
bounds checking support, enabled by default in debug mode, and selectively in
release if one so wishes.

Ideally, Swift, Rust, Ada, .NET Native would have replaced all use cases, but
we are far from that ideal, so 2nd best solution, C++ for the time being.

Note that Apple and Google also reduce to the minimum the usage of C, and
equally advocate C++ instead, alongside their managed languages for their
OSes.

So yeah, you get C11 in the box, pity that the OS APIs are a mix of C++ and
their own languages.

~~~
flohofwoe
C++ as OS APIs (which so far only Microsoft seems to do in their UWP wrapper
APIs, which is a fairly exotic use case) can be dealt with the same way as
Objective-C on macOS and iOS: put all the code which talks to OS APIs into
separate C++ or Obj-C source files, and put that code behind a simple C-API.

It's also interesting to note that Microsoft is only using header-only C++
wrappers, under the hood it's all plain old C-APIs via COM (because it would
be a bad idea to expose C++ APIs in system DLLs).

The usage rules for C++ in Google's Fuchsia are so limited [1] that it is
essentially a "C with classes", and it also has the rule that all shared
libraries must have C APIs. I really don't see the advantage of using C++ for
the underlying implementation compared to plain C if C++ has to be stripped
down that much, and the public APIs are C APIs anyway.

[1] [https://fuchsia.dev/fuchsia-
src/development/languages/c-cpp/...](https://fuchsia.dev/fuchsia-
src/development/languages/c-cpp/cxx)

~~~
gpderetta
Doesn't seem extremely limited at all:

\- Exceptions, RTTI, thread_local, Statically constructed object all require
runtime support and are problematic in a kernel so it is not surprising \-
Virtual inheritance: almost litterally nobody uses it. \- initializer lists
require static storage which is also problematic in a kernel \- operator
overloading and trailing return types are a stylistic choice, but at the end
of the day they are a tiny bit of C++

Things that are allowed: actual OO classes inheritance (including multiple
inheritance), virtual functions, RAII, templates (no restrictions at all),
lambdas, all the recent goodies. I.e. all the things that make C++, well, C++.

So it is way less restricted than other guidelines I have seen for well known
C++ projects.

------
in3d
Compiler support:
[https://en.cppreference.com/w/cpp/compiler_support](https://en.cppreference.com/w/cpp/compiler_support)

Some features listed as supported are in their experimental versions still but
it’s coming along pretty well.

------
brewmarche
As someone who's only had C++98 experience in a code base that leaned more
towards a Java style, are there some good guides or books on a more modern C++
style?

~~~
dgellow
A Tour of C++ 2nd Edition, by Bjarne Stroustrup

[https://www.stroustrup.com/tour2.html](https://www.stroustrup.com/tour2.html)

> The ``tour'' is a quick (about 240 pages) tutorial overview of all of
> standard C++ (language and standard library) at a moderately high level for
> people who already know C++ or at least are experienced programmers. It
> covers C++17 plus a few likely features of C++20.

I will add that it's a good way to have an overview of modern C++, you can
then go deeper on some topics with more specialized resources. It's a good
read IMHO, with a good pace.

~~~
brewmarche
Thank you!

~~~
dgellow
You're welcome :)

If at some point you're looking for more specific resources, I would suggest
to ask on the C++ subreddit. I found people there to be helpful.

------
ausjke
I'm actually actively learning modern c++ these days, and I like it so far.

On another note, Bjarne is 70 year old and he is still very active in c++ new
features, very impressive. That gives me a hint that as a software engineer, I
can be productive for many years to come as long as I keep studying.

I also hope Linus still maintains Linux kernel in the next 20 years.

------
rambojazz
Well, wasn't there any other more informative link than a tweet?

~~~
dgellow
That’s a tweet from a committee member, just when the version had been
approved. You can find a lot of resources in the other comment threads if you
want to see more details.

------
einpoklum
Great, now we just have to wait for about 7-8 years or so for all of these
features to be widely adopted, and then we're good to go!

~~~
dgellow
C++20 compiler support is already quite good among the main compilers (GCC,
Clang, MSVC):
[https://en.cppreference.com/w/cpp/compiler_support](https://en.cppreference.com/w/cpp/compiler_support)

~~~
einpoklum
I'm talking about:

1\. Adoption by users, including the larger, sluggish, corporate ones (and I'm
being lenient with 8 years).

2\. Transition from headers to modules.

~~~
dgellow
> 2\. Transition from headers to modules.

Yeah, this one is likely to take a while...

------
pkrumins
This is another sad day for us, C++ programmers. Even more features have been
added to the language that we didn't ask for and that are nearly impossible to
learn and use in practice.

~~~
yanndsal
What features weren't asked for as opposed to what was implemented that was
asked for?

