
C++20 Design Is Complete: Modules, Coroutines in C++20 - ingve
https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso_c_committee_trip_report_c20/
======
waynecochran
I am still trying to understand when T&& is a r-value and when it isn't.

[https://isocpp.org/blog/2012/11/universal-references-
in-c11-...](https://isocpp.org/blog/2012/11/universal-references-in-c11-scott-
meyers)

I feel I will never master C++ -- neither will Stroustrap.

[https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c...](https://www.theregister.co.uk/2018/06/18/bjarne_stroustrup_c_plus_plus/)

~~~
CJefferson
I used to be on the c++ committee and contributed to both gcc and clang. That
T&& r-value mess, along with c++ still having no built in method to print a
vector, are the straws which persuaded me to abandon c++. It seems designed to
be confusing.

~~~
Something1234
> c++ still having no built in method to print a vector

This a thousand times. All the best languages have a good way to print out a
structure, and allow interactive inspection. Instead with C and C++ we have to
suffer with debuggers rather than just using good old print statements.

~~~
pjmlp
Enjoying the productivity of debuggers since mid-90's, with ability to
graphically display data structures.

Printf debbuging is the actual suffering.

~~~
jstimpfle
You think that print debugging is wrong and debuggers are the way to go?

~~~
pjmlp
Definitely, printf debugging is a tool left for the few cases where a proper
debugger, jtags, intelitrace, dtrace, jmx, flight recorder, and other similar
technology isn't available.

~~~
jstimpfle
With a graphical debugger, how do you produce a log-trace of what your program
did?

How do you show a table of just the information you need, to help you find a
bug? What if the table is a join of multiple datastructures from distinct
locations?

How do you, after stepping forward through the code until you reach a certain
configuration, make a small modification to the logic, so that you can replay
from the start with the intent to reach a slightly modified configuration?

Are graphical debuggers on par with simply print debugging to notify when a
particularly complicated situation occurs that can only be described by a
complex logic?

~~~
pjmlp
I mentioned already a few possibilities, as I was expecting that question.

Edit: Since you edited your question after I replied, all those use cases are
still covered by intellitrace, dtrace, flight recorder, jtags, with the
benefit of not having to recompile the code.

Naturally you can come up with wicked examples that those tools don't cover,
then again they will be most likely irrelevant for the large majority of devs.

~~~
jstimpfle
Which raises the question, how are these not print debugging? How are they
better than print debugging?

I admit I don't know any of these tools, but I hope (1) they don't introduce
another language than the one the project is coded in, (2) they let you put
the logging statements inline in the code since otherwise the debug setup
would be hard to synchronize to the actual code.

The situations I described are not particularly wicked, but rather normal
debugging. If the bug is not trivial (in which case an interactive debugger
can help finding it quickly), then the process is always to start with a
global but coarse view, decide where the bug likely is, and zoom in on that
partial view, requesting more details.

I doubt any automated system can help much there. Automatic structure printing
might already not work for many cases since it prints too much data, or
formats the data in a way that is too mechanical and not fitted to the task.
Or in case of object-languages, the system does not now how "deep" it should
print these structures.

I think automatic structure printing is a nice to have for simple situations
with few structure fields. In practice I'm almost always fine with typing a
printf line manually. I don't think that typing and modifying the line as I go
would take the majority of my debugging time.

I use interactive debuggers myself, and I think they are faster in simple
cases since there is no edit-compile-rerun cycle. But like all interactive
GUIs, they are not (or only badly?) scriptable and automizable.

~~~
pjmlp
They are better than print debugging because they allow to even instruct
applications in production without having to do any change to the application.

Stuff like DTrace and Intellitrace have OS level support to integrate with the
application being instrumented, execute whatever actions are required and
interoperate with the debugger. Intellitrace even goes as further as
supporting time travel debugging.

Yes some of them, e.g. DTrace, do have their own little scripting languages.

------
yingw787
Wonderful news! I don't use C++, but I appreciate how at the end of the day,
C++ will always be with us, and so will its benchmarks/expectations, battle-
tested tooling ecosystem, and generously bestowed developer power. Makes the
rest of us strive that much harder :)

~~~
pjmlp
I am with you.

As managed languages dev, I seldom use C++, but when I do it is the best
system language currently available regarding tooling, libraries and hardware
support (NVidia now makes GPGPU optimized for C++ semantics).

For app development, there aren't many scenarios where C++ is really
necessary, whereas for systems it is going to stay around for years to come.

So anything that helps improving the quality of GCC, LLVM, CUDA, UWP, Metal
Shaders, DirectX, Unreal/Unity/CryEngine/Cocos/Godot is more than welcome.

For anything else, we can just follow Microsoft's security suggestions as
presented at Blue Hat IL, namely C# (replace by favourite managed language),
Rust and modern C++.

[https://github.com/Microsoft/MSRC-Security-
Research/blob/mas...](https://github.com/Microsoft/MSRC-Security-
Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf)

~~~
DSingularity
How is gpgpu optimized for c++ by nvidia?

~~~
pjmlp
Since Volta, NVidia GPUs are designed taking into account C++'s semantics.

[http://cppcast.com/2017/09/olivier-
giroux/](http://cppcast.com/2017/09/olivier-giroux/)

[https://m.youtube.com/watch?v=86seb-
iZCnI](https://m.youtube.com/watch?v=86seb-iZCnI)

------
yodon
The surface area of C++ 17 is so huge it's already largely a write only
language (impossible for a normal maintenance programmer to have learned and
mastered all the syntaxes and idioms). I'm not looking forward to trying to
maintain a C++ 20 codebase that a bunch of architecture astronaut devs went
wild on.

~~~
beached_whale
That is a conversation with who you work with. You don’t use all the tools in
the garage but are really happy they are there when you need them.

Also, a large part of modern c++ is that simplicity is not only better for
people but for compilers.

~~~
seanwilson
> That is a conversation with who you work with. You don’t use all the tools
> in the garage but are really happy they are there when you need them.

When a language contains lots of ways to shoot yourself in the foot, it's just
not realistic to expect that those features aren't going to be misused when
potentially millions of programmers might be coding in it. Even getting
agreement of how to use features within a small team can be difficult, and
you're always going to have to use external libraries developed by others that
don't follow your coding standards.

The language design should make it easy to do the right thing and difficult to
do the wrong thing in my opinion. When the language isn't designed this way,
it's always an uphill struggle where the coding community has to devise and
enforce their own standards.

~~~
beached_whale
Often, not always, the other side of that shooting in foot is a very useful
tool for another purpose. And it is unattainable to code review other
libraries, put the hard stop at the API boundary. But yeah, that can force
your hand in some decisions too... It's complicated

I am of the mind that any language that is useful for general purpose or at
least outside of small niche areas will provide many ways to shoot yourself in
the foot. C++ does have a lot of them, but it also has a lot of tools.

------
ingve
More info in Herb Sutter's Winter ISO C++ standards meeting (Kona) trip
report:

[https://herbsutter.com/2019/02/23/trip-report-winter-iso-
c-s...](https://herbsutter.com/2019/02/23/trip-report-winter-iso-c-standards-
meeting-kona/)

~~~
mattnewport
I was happy to see coroutines make it in but some of the concerns raised about
the design seemed to have valid points. I'll be interested to read the papers
mentioned when they're available to see how a consensus was reached and what
the plans for the future are.

~~~
gpderetta
There were at least 4 different competing coroutine proposal at the last
mailing. I guess the committee didn't see any hope and convergence and just
opted for the more mature proposal.

------
azhenley
After working with Go for the last few months, looking at these C++20 examples
just baffles me. So many symbols, keywords, and library calls. It really makes
me miss C.

I wonder how long it would take to learn C++ now.

~~~
ilovecaching
Give Rust a try. People like to complain about the Rust learning curve, but
comparative to the language it's trying to replace (C++) it's actually _quite_
simple and the compiler/tooling will hold your hand compared to the
conventions you have to memorize to use C++17 safely.

~~~
banachtarski
Not OP but i keep trying and the tools still have a long way to go and compile
times are abysmal (even relative to C++). For example,
[https://github.com/rust-lang/rls-vscode/issues/237](https://github.com/rust-
lang/rls-vscode/issues/237) this issue that has persisted for over a year with
no signs of being fixed.

With C++, in spite of its warts, I can still be productive just because of the
ecosystem around it. Rust was something I was gung-ho about, but after
repeated attempts to create a medium/large project, I am still in a wait and
see mode. Moreover, it's just not powerful enough. Many features are coming
in, but they break the compiler and you end up needing to work off nightly
regardless. I think it's a good effort, but people just recommending the Rust
train nonchalantly really need to step back and check their biases.

~~~
ilovecaching
I don't think using a vscode plugin as an example of Rust not being ready is
very fair. You could always fix the issue yourself, it is open source you
know.

My original point was that we shouldn't be building monolithic projects in a
single language, but if there is an absolute requirement for it, Rust compile
times aren't that bad. C++ also has very long compile times, it just comes
with the territory. The reason Go can compile in under a second is because
they purposefully keep the language specification simplistically small.

I'm not recommending Rust nonchalantly. I write rust _every day
professionally_ , and I basis my opinions on the experiences I've had with it
in that environment.

~~~
banachtarski
It is fair because there are very few options for _authoring_ Rust code.
Regardless of who is responsible, a robust and working toolchain is sort of
the minimum bar for a language, and yes it's open source, and yes I've looked
at the code, but no it's not worth the time right now because better options
exist. I'm super familiar with C++ compile times but again, there exist a lot
of infrastructure to at least help with that or eliminate it completely (with
some tricks). I'm not saying Rust will never get there, but for me, too soon
too early.

------
atombender
Anyone know how the modules problems were resolved? There were rumblings that
the technical challenges around build systems and dependency resolution were
blocking items (e.g. as explained here [1]).

[1] [https://build2.org/article/cxx-modules-
misconceptions.xhtml#...](https://build2.org/article/cxx-modules-
misconceptions.xhtml#build)

~~~
lossolo
You can read about it here:

[https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso...](https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso_c_committee_trip_report_c20/eh4rg0m)

------
altairiumblue
As someone who doesn't use C++, can anyone explain in a straightforward way
why a low level language is going through so many new versions?

And is there big difference between the latest version and C++ from 5 or 15
years ago?

How do you guys keep up when a huge language is continually changing?

~~~
GeneralMayhem
>is there big difference between the latest version and C++ from 5 or 15 years
ago?

As compared to 15 years ago, the language is almost unrecognizable. As
compared to 5 years ago, it's a bit more convenient to use, but not wildly
different. C++ is a relatively old language, but it didn't have an real
standard until 1998, and even that version was more about documenting what was
out there rather than prescriptively designing anything. Before that (and to a
lesser extent since, cough-cough-Microsoft-cough), it was a mess of
incompatible OS features, compiler-specific semantics, and inconsistent
tooling. In the right environment, it could be the most amazing and productive
language, but it was a very short trip from "this is great" to "here be
dragons and assorted hellbeasts".

C++11 has been by far the biggest change. Beyond the huge impacts on the
language itself, it was the beginning of the current standards cadence of new
standards every 3 years. To point to a single feature, C++11 introduced smart
pointers and move semantics, which are the only "modern C++" features that I
use in almost every single source file.

>How do you guys keep up when a huge language is continually changing?

A new version every 3 years is not that fast, really. And the new features are
totally opt-in and backwards compatible; code written decades ago will, for
the most part, still compile today. That means that you can slowly adopt new
features one at a time as they make sense.

>why a low level language is going through so many new versions?

First, C++ isn't really a low-level language - or at least, it doesn't have to
be. It hits a really interesting sweet spot where you can express powerful
things concisely, and yet predict more or less exactly how things will execute
if you think it through. It doesn't run on a VM like Javascript or Python, and
it doesn't have the esoteric abstractness of Haskell, but it's certainly much
higher-level than C, and there are a number of layers farther down than that.

Second, the reason for the iteration mostly has to do with filling in features
that everyone had to build for themselves, and which were often platform-
specific. Each version has progressively expanded the standard library with
things like cross-platform concurrency primitives (std::mutex, std::thread),
file I/O (<filesystem>), efficient string manipulation (std::string_view), and
improved templated containers (std::optional, std::variant). Adding smart
pointers in C++11 was about moving best practices about memory management into
the language. Adding file I/O in C++17 was about standardizing cross-OS
compatibility layers. Adding modules in C++20 is about improving standard
buildchains and package management. Prior to C++11, every organization had to
have their own implementations of all of those things, which required a
massive investment into internal "standard" libraries, styleguides, and
tooling, which were totally incompatible with each other. In the modern C++
era, a lot of those things can be the same for everybody, which makes
everything more efficient - easier to transfer to a new codebase, easier to
start from scratch, easier to share tools and libraries.

~~~
heyoni
I think that teaching myself C++ in the late 90’s was a mistake. I remember
going through an entire textbook, not being able to do anything with it and
stopped programming for years.

~~~
pjmlp
Depends pretty much on each one.

Coming from Turbo Pascal 6.0, it provided me a world with access to C based
tools, without having to endure typical C unsafe code.

~~~
heyoni
Absolutely. For me it was something I was doing for fun when I was about 13
and was my second intro to programming after qbasic.

------
NotANaN
The fact that C++ versioning uses two digits for the year is the most 1980s
thing about it.

~~~
cpeterso
If C++ continues to release a new version every 3 years, 2098 will be C++98
again. So either the language designers don't think C++ will survive to 2098
or they will need to change their versioning.

~~~
wilonth
We can then skip that 98 and go straight to C++101.

~~~
Narishma
I think you meant C++XP.

------
rienbdj
Very disappointed that coroutines will be included in their present form. Did
the committee just want to push something out?

~~~
smallstepforman
A good solution today is better than a potentially better solution tomorrow.

~~~
jcelerier
it really depends. if the accepted coroutines hides memory allocations willy-
nilly, it means that there is a whole body of code that will never ever use
coroutines in their code. While waiting for non-magic-allocating coroutines
would have made those better in five years.

------
chombier
So most notable new language features are modules, coroutines, concepts and
contracts. That's huge!

I remember vaguely that there were some issues with the initial module
proposal and multiple (concurrent :) coroutine designs.

Does anyone know what the problems were and how they were resolved?

------
cmrdporcupine
"TL;DR: C++20 may well be as big a release as C++11."

I feel like with the addition of modules this may be a release of the language
spec that is going to need at least a decade to settle in. I hope the next few
changes are more incremental.

I am very excited for modules. Hell, maybe I'll even see them used some day in
the chromium code base I work in.

------
waynecochran
C++ compiler authors must practically be gods to translate this stuff. There
are so many parsing problems — quantum mechanics is child's play.

~~~
abhishekjha
Query: Would the compiler writers have to write compilers from scratch for
C++20 or the features can be added without overwriting the entire system?

I am aware that new features means a few parts needs be rectified. But does
the whole need to change?

And I agree for C++ compiler writers to be gods. Looking at the source code
for GCC/clang makes me doubt my programming skills. Same goes for the linux
kernel source code.

~~~
lallysingh
It's the parser (context dependent) that's hard. The rest is a regular
compiler that you can learn to write out of a textbook.

And the parser is hard in pain-in-the-ass terms, not CS theory terms.

[https://raw.githubusercontent.com/gcc-
mirror/gcc/master/gcc/...](https://raw.githubusercontent.com/gcc-
mirror/gcc/master/gcc/cp/parser.c)

~~~
bsenftner
If the parser is hard to write, that means the syntax is conditional upon
previous statements, which I've not seen in the spec. As long as the syntax is
Lexical, no real issues parsing. How does the context throw curves?

~~~
lallysingh
I did say context dependent, which is the opposite of context free.

~~~
waynecochran
Yes. May need to back track due to context sensitivity. A quote from the
source comments:

    
    
        Some C++ constructs require arbitrary look ahead to disambiguate.  
        For example, it is impossible, in the general case, to tell whether 
        a statement is an expression or declaration without scanning the 
        entire statement.
    

I am sure there must be some devilish source code examples that require an
exponential search for the correct parse. Also, has anyone constructed a
modern C++ parser in bison which can backtrack?

~~~
lallysingh
Gcc 3.3 and before had one, but they decided to write one by hand going
forward. I don't think it's reasonable to do so without keeping context.

------
FrankDixon
I wonder if this really makes sense. In the long run, C++ will be even more
massive than it is now. A hundred ways to do sth. Meanwhile, new, lean, langs
jump up all the time: crystal, nim, swift, rust. I wonder how long the
momentum can carry C++

~~~
sprash
C++ will never die because it is the only language that really owns the "zero
cost abstraction" business like no other language.

------
pjmlp
Modules are in! Great news.

------
sprash
Yay, even more features and complexity. Will they ever stop?

It already takes years to really master C++.

Soon you will be unable to read and understand C++ code without googling every
second line.

------
Jerry2
Since the language is shifting and changing so fast, how do teams pick style
guides and coding standards for multi-year projects?

~~~
bad_alloc
In my experience you stick with a certain version, even as new stuff comes up.
My current work is in C++14 and will not move to newer versions.

~~~
therockhead
What are the reasons for not moving? We are currently on C++ 17 and we need to
support Windows, macOS,iOS and android.

~~~
gmueckl
One reason: consistency. When you introduce new features, idioms shift and
maintaining code that uses multiple idioms for similar purposes is simply less
fun. In the worst case you make changes harder because you now have to make
your changes compatible with more modes of usage.

------
sigmaml
Opened the coroutines draft just now. I like the humour in the note at the
bottom of Page 1!

------
sagartewari01
C++ is no longer C++. It might have been that at some point, but nowadays,
it's more like C plus e'th root of pi.

~~~
waynecochran
Even the name "C++” is inane.

I have a love / hate relationship with C++ — without the love.

------
mruts
I consider myself an expert on C and I always used to put C/C++ on my resume.
But it occurs to my that C and C++ aren’t really similar anymore and that I
don’t really know C++ at this point.

I’ve always despised C++ but that’s when it was pretty similar to C. It seems
to have gotten exponentially more complicated but also it seems like it’s
pretty expressive at this point: potentially supporting Rust-like safety and
FP-like design.

Maybe someone who’s an expert can tell me how different C++20 is from C?

~~~
IshKebab
Very very different. Don't put C/C++ on your CV if you don't know C++. You'll
just annoy employers who are looking for C++ developers.

------
denart2203
This is super exciting! Big congratulations! I only wish that C++20 gets a
wide adoption as quickly as possible once its released.

------
devwastaken
I've been fighting c++ recently with qt. Something as simple as iterating over
widgets on a page isn't possible without casting to every kind of child widget
and checking it. I get why, it's because if static typing, but I wonder if
it'd ever be possible to 'type hint' and make it possible to implicitly
downcast. For example qt will let you iterate over QWidget * type, but you
gotta cast it to the real type of QLineEdit and such to get the widgets
values.

Of course the 'c++' way is doing event listeners and recording data when it's
changed.

~~~
ahartmetz
A tangent on ways to do it with Qt, because I don't like seeing Qt presented
in a bad light due to unfamiliarity.

With Qt you can chain QObject::metaType(), QMetaObject::className(), int
QMetaType::type(const char *typeName) to get an integer you can use to switch
() on type. It is, I believe, possible but obscure on purpose because it is
not meant to be used willy-nilly. You can also access Q_PROPERTYs by name
using QObject::property(), and Qt's own classes have the same names for the
same properties where it makes sense - such as text() in QLineEdit and
QAbstractSpinBox etc.

It depends on your requirements if using that approach actually makes sense. I
haven't seen it used yet... If you want to serialize GUI state, a more
intrusive design where, say, you keep some helper data on the side to allow
"dumber" code in the actual de/serialization might be better. Or just wire up
the widgets to a model (QAbstractItemModel and / or QObjects exposing
Q_PROPERTYs - that's how you do it with QML if you do it right) and use the
model as the main source of truth and, of course, for serialization.

The "high level debugger for Qt" GammaRay is a nice showcase of what you can
do with Qt's introspection capabilities. Qt had ~3 extension points added for
GammaRay to observe object lifecycles, most everything else is based on pre-
existing functionality.

~~~
devwastaken
How do you use QMetaType::type without having to do the same as I said, which
is explicit casting? afaik there's no way to get the 'real' type that you can
shove into qobject_cast or dynamic_cast to turn QWidget into a QLineEdit. The
only way is to write in the type and try each cast, you can't store types in
some map and go 'get' the type at runtime to have casted.

~~~
ahartmetz
Yes you will have to cast eventually, and no you won't have to try casts.

~~~
devwastaken
You'd have to point out specific code for that. Afaik that's not possible in
c++ at runtime. Compiler has to know the type even in dynamic casting.

~~~
ahartmetz
I actually think I've given you all the info you need. You switch on type ID
and cast to the then known type.

------
doctorpangloss
I have mixed feelings.

On the one hand, C++ has created generations of Visual Studio GUI addicts.
Imagine how much further software would have advanced by now if the average
person (a Windows user on a crappy laptop) had good, free tools to make web
and mobile applications. Two things VS and C++ are just really bad for, if you
inhabit reality.

And all those stubborn people who are going to reply insisting otherwise, how
much better would the world be without them? Just kidding guys, hang in there.

On the other hand, less competition! Long live C++!

~~~
mayank
> C++ has created generations of Visual Studio GUI addicts

C++ has been used outside of Windows since basically the inception of C++.

~~~
gumby
C++ predates Windows.

