Transcript
Discussion (0)
Hi, I'm Gleb from London. I run a C++ club at work where we discuss C++ programming news and related articles.
You can find our meeting notes at cppclub.uk.
This podcast and the meeting notes contain public information only.
This is episode 8 for the meeting number 133 that took place on the 8th of July 2021.
The June 2021 mailing is out.
The following papers caught my attention.
Stud Execution P2300, Version 0
by Michal Dominjak, Lewis Baker, Lee House,
Michael Garland, Eric Niebler, and Bryce Slelbach.
Quote, this paper proposes a standard C++ model for asynchrony
based around three key abstractions, schedulers, senders, and receivers,
and a set of customizable asynchronous algorithms.
End quote.
It aims to replace the existing executor's proposal, which is currently at revision 14.
This paper is not a patch on top of that executor's paper.
We are not asking to update the existing paper.
We are asking to retire it in favor of this paper.
This paper is not an alternative design to the executor's paper.
Rather, we have taken the design
in the current executor's paper
and applied targeted fixes
to allow it to fulfill the promises
of the sender-receiver model,
as well as provide all the facilities
we consider essential when writing user code
using standard execution concepts."
According to GitHub Notes, essential when writing user code using standard execution concepts."
According to GitHub notes, it has been discussed in a joint telecon by library evolution and
concurrency groups.
Among other topics, they discussed how coroutines work with the new proposal.
The authors think coroutines cannot express all aspects of the sender-receiver model, like cancellation.
One of the main points was the current network in TS and if it should remain coupled with executors' sender-receivers.
Quote, some said out that we have been trying to develop a grand unified async model for years and perhaps that is a mistake. Others pointed out that it may
be a mistake to try and retrofit the networking TS which is based on established practice from
Boost.azio with a new model." The networking TS has been in development for a long time
with no end in sight. The committee are now going to have to make a decision between shipping it as is, based on ASIO,
or abandoning it in favor of something else.
Either way, the community won't be happy with yet another delay.
Pattern matching using is and as.
This is a paper by Herb Sutter.
The proposal builds on the existing pattern matching
paper and adds the new keywords to the language. Is for matching constraints and as for all
cast scenarios except reinterpret cast. In addition, the structured binding syntax is
generalized to allow nesting and while cards. Herb Sutter proposes that the new matching syntax is allowed
not only in inspect statements of the original pattern matching paper,
but throughout the language, including if statements and requires clauses.
I so hope that we get pattern matching in C++23,
and this proposal seems like a sensible idea built on top of that.
If it gets pattern matching adopted faster and makes it simpler to use, it's a good thing.
Efficient seeding of random number engines.
This is a proposal by Moritz Klamler.
The purpose of this proposal is to make properly seeding a random number engine
in a non-deterministic way easy and fast.
The changes are non-breaking and can be implemented as a pure library solution
with current C++20 features. C++ introduced random number generation
facility with the header random. However, there is no way to seed the RNG properly
with std random device.
The code most people use is severely flawed.
A better way is to use a seed sequence, but the code required is long and non-trivial.
The proposed way is much simpler and more thorough.
Stack trace from exception.
This is a proposal by Andrey Nekrashevich and Antoni Polukhin.
This paper proposes a new function, std stack trace from current exception,
which can be used in a catch clause to dump stack trace corresponding to the current exception.
It looks like a very useful feature which would bring C++ just a little bit closer to Java,
which as we all
know is a language that converts XML configuration files to exception stack traces. Implementing
this could be expensive though, as the stack information would need to be propagated through
the exception handling machinery, making it potentially less efficient. The last paper is Abort Only Contract Support.
This is a proposal by Andrzej Krymenjski and Gaspěr Ažmán.
This paper proposes a minimum viable product for the much delayed contracts feature of C++.
It would serve as the first phase of introduction of the full contracts whenever that happens.
The goals of the paper are be a coherent whole and provide a value to multiple groups of
developers be small enough to guarantee that it will progress fast through the standardization
pipeline and be devoid of any controversial design issues.
This is to obtain the maximum consensus.
Good luck with that.
The proposed precondition can result in either no action or a runtime check that results
in programmer bot if it fails.
I wonder how much discussions and controversy this one will generate.
Next, MatchIt.
Speaking of pattern matching, MatchIt is a lightweight header-only pattern matching library
for C++17 with a macro-free API.
It's a single header, doesn't allocate heap memory, is cross-platform, constexpr-ready,
doesn't have external dependencies, supports composable matching and user-defined patterns.
There are many examples and even migration guides from Rust and from the pattern matching proposal
itself. The Reddit crowd is very impressed by the library and especially by the absence of
macros in the API. Of course, this leads to a side discussion on why macros are bad. This is what Redditor
Grassicod says. Macros are textual and have no idea what C++ is and what C is. They don't have
scope, cannot be isolated, and create all sorts of problems, especially since C++ is using headers to consume declarations from other translation units.
Redditor Foundry27 disagrees.
I'd argue that the biggest problem with preprocessor macros is the community's general lack of familiarity with them,
general meaning for the general C++ programmer,
and the near total absence of teaching material
for how to use macros in a safe, effective manner.
To this, Johannes1971 replies,
this completely misrepresents the position of the community.
The dislike comes from all the bad shit macros do, not a general lack of understanding.
I don't know how production-ready this library is, but it surely looks impressive.
And since we are unlikely to get the official language pattern matching until at least C++26,
this may just become a usable replacement.
I so hope I'm wrong here and we get it in C++23.
Next, FMT 8.0.
The excellent text formatting library FMT by Viktor Zverovich reaches version 8.
Some of the new features include
Compile time formatting string checking enabled by default, but needs C++20 const eval.
Much faster format string compilation, new format string literal underscore cf,
which replaces the fmt underscore compile macro,
and initial support for compiling fmt as a C++20 module.
The article A Quest for Safe Text Formatting API by Viktor Zvirovich
provides some background for the compile-time format
string checking in FMT, including dynamic extensible formatting and zero-overhead format
string compilation.
Apparently what FMT does is not trivial to do in Rust in an extensible way.
Next, FTX UI, a C++ functional terminal user interface.
Arthur Sanzogny from Paris created a remarkable user interface library based on reactive programming
paradigm.
Redditors say that the library looks great and its API is simple and elegant.
It is also compatible with WebAssembly, so the examples can be used from the browser.
They look pretty impressive, too. The library also supports Linux, macOS, and Windows, has keyboard
and mouse navigation, implements all the standard controls, and can be used instead of a GUI.
The programming constructs it uses remind me of SwiftUI, a declarative UI framework for Apple platforms.
FTX UI is used by several projects, among them Git2e, a rich Git console interface by the same author.
Next, size-type convention, or size-t, confuses people again. A Redditor asks what should they use for length
of an array sizeT which seems like a natural choice or some other type. Most replies tell
the original poster to use the sizeT as it's used everywhere in the library but some advise
using a signed type and the original poster is not sure about this.
They say, why would I use a signed type?
Array length and memory size can't be negative.
This prompts a link to Bjarne Stroustup's paper.
Subscripts and sizes should be signed.
Redditor Entello says, negative values resulting from erroneous logic are easy to detect early,
and signed overflow has undefined behavior.
This makes signed types safer for representing non-negative integers.
It may seem counterintuitive, but that is in fact the case.
Overflow of integers representing numbers, as opposed to, say, bit bitmasks is almost always a bug. In the case
of unsigned types the compiler and other tooling has no choice but to assume that you the programmer
intended for overflow to occur. In case of signed types however the undefined behavior allows for
more freedom. Trapping, like causing a fault which
would crash the program immediately,
is a valid manifestation of undefined behavior.
In addition, this situation can be
detected by a variety of analysis tools,
either statically or at runtime.
Redditor ioctl79 says, there are existing tools
for identifying and trapping undefined behavior.
If you use unsigned types,
you opt out of all of those.
Another radiator replies with a useful information.
Clang UBSUN,
undefined behavior sanitizer,
has fsanitize equals unsigned integer overflow.
And lastly, C++20 has std ssize function and the tag is equals unsigned integer overflow.
And lastly, C++20 has std s size function that returns std ptr diff underscore t type,
which you can use to sort of fix the original unfortunate decision
of using std size for sizes in the standard library.
That's it for today. And I'll leave you with a quote and a
picture that I will try to describe. It's true love via Reddit. The first picture says,
the pupil of your eye can expand over 45% when you see something you love the next slide shows the fully expanded people
looking at the message on the screen says saying code compiled successfully
that's it thanks for joining me today and i'll speak to you soon goodbye