160. C++ Bookcamp, WG21 April mailing, Contracts, Rust, Circle
With Bjarne Stroustrup, Frances Buontempo, Gianluca Delfino, Joel Daniels, Vladimír Arnošt, Ivor Hewitt, and other colleagues.
Media
Video
Podcast
Powered by RedCircle
Guest: Frances Buontempo
See also:
C++ is an old but evolving language. You can use it for almost anything and will find it in many places. In fact, C++’s inventor Bjarne Stroustrup described it as the invisible foundation of everything.
Target audience:
This book is aimed at people who have used a little, or even a lot, of the language and lost track of recent changes.
The book encourages the reader to try out the code examples, and the live version has a copy button for code snippets. The inline links to relevant information (articles, videos, etc.) are especially useful.
- A small thing, but thank you Frances for not using
std::endl
in the example code! - While discussing a particular task, the book explains all the aspects of C++ needed to solve it, as opposed to dedicating a separate chapter to a single C++ topic. This feels closer to how C++ is used in practice.
Feedback on earlier feedback
Roi Barkan mentioned in a YouTube comment a paper on using auto{x}
for decay-copy, due to which it couldn’t be used for the proposed short concepts notation.
The paper seems to have been accepted (plenary-approved) for C++23:
- P0849R0 by Zhihao Yuan
- WG21 GitHub page
- Steve Downey’s C++23 status
AMA with Bjarne Stroustrup on Exercism channel
Some silly questions in the chat, like ‘what do you think of Rust?’ and ‘what about ChatGPT?’, and ‘vim or emacs?’, and ‘why is c++ so hard?’, but some good questions too.
WG21 April mailing
Paper: do
expressions
- P2806R1 by Bruno Cardoso Lopes, Zach Laine, Michael Park, Barry Revzin
Paper: Uniform Call Syntax for explicit-object member functions
- P2818R0 by Gašper Ažman
This paper introduces a unification of hidden friends and explicit-object member functions to allow a limited, but hopefully uncontroversial Uniform Call Syntax for them. Unlike the previous proposals on this topic, this one avoids pretty much all controversy.
I imagine committee members seeing this and going “I’ll be the judge of that!”
1struct S {
2 friend int f(this S) {
3 return 42;
4 }
5};
6
7int g() {
8 S{}.f(); // OK, returns 42
9 f(S{}); // OK, same
10 (f)(S{}); // Error; f can only be found by ADL
11}
Paper: Trivial infinite loops are not Undefined Behavior
- P2809R0 by JF Bastien
C and C++ diverge in their definition of forward progress guarantees, and have done so since C++11 and C11 added a memory model and acknowledged that threads exist. <…> C does not make iteration statements whose controlling expression is a constant expression Undefined Behavior, whereas C++ does. C++ implementations therefore assume that even “trivial” infinite loops must terminate. This is unfortunate because using an infinite loop is a common idiom in low-level programming, particularly when a bare-metal system or kernel must halt progress.
Paper: Contract-Violation Handlers
- P2811R1 by Joshua Berne
Custom violation handlers turn an overly simplified Contracts facility that is highly ineffective in many environments into a moderately flexible and practicable one.
Paper: The idea behind the contracts MVP
- P2817R0 by Andrzej Krzemieński
Paper: Unconditional contract violation handling of any kind is a serious problem
- P2838R0 by Ville Voutilainen
This paper explains why we shouldn’t have hard-coded Eval_and_abort and Eval_and_throw modes in the Contracts MVP, and further explains why we should have a violation handler instead.
The problem is that hard-coded violation handler semantics don’t scale. For Bjarne’s concerns, if there’s any translation unit anywhere in a program that terminates on contract violation, that translation unit needs to be recompiled. If another user doesn’t want contract violations to throw exceptions, the same problem occurs, any translation unit that has been compiled with a throwing violation handler strategy needs to be recompiled.
Stop Comparing Rust to Old C++
People keep arguing migrations to rust based on old C++ tooling and projects. Compare apples to apples: a C++20 project with clang-tidy integration is far harder to argue against IMO
A refreshingly calm discussion on the pros and cons of both Rust and modern C++. For example:
Pros:
There is a lot that Rust has going on for it that C++20 does not have. Leaving out the usual memory-safety and thread-safety language features that people are probably aware of already:
- build system stuff and dependency management and even packaging (for simple enough apps) are basically a no brainer in Rust. coming from C++ this alone is life changing
- moves are destructive, so there is no use-after-move, no fuzzy moved-from state
- pattern matching as a language feature is incredibly powerful, and it’s not bolted on after the fact as it maybe will be in C++ but the language was designed around it (a point of envy for me)
- most defaults that people often wish were different in C++, starting from constness and barring surprising implicit conversions, are fixed in Rust
- unit and integration testing is also part of the language and unit tests can be put next to the code they test
Cons:
As someone who uses both Rust and C++ near-daily, I always miss C++’s type system in Rust. Rust’s type tools are very weak by comparison and the fallback, proc macros, are a royal pain.
I’ve been working on an archetype ECS library for games. This is essentially a processing engine for arbitrary tuples in struct-of-array data structures. The lack of variadics and the weakness of trait expressions (no specialization, no negative constraints) combined with the orphan rule has made it pretty unpleasant to do in Rust. If I want the work to be done at compile-time for runtime performance reasons, I’m basically stuck with one giant megacrate containing all of the code in question created by very heavy proc macros.
Most popular ECS libraries in Rust rely on a lot of RTTI and reflection-like functionality that isn’t zero-overhead. The equivalent library I’ve written in C++ is almost entirely compile-time with variadic tuples and tuple-processing functionality (like using SFINAE to find all types in a type tuple that have a given function).
Rust enums are great, but Rust generics are nowhere near as powerful as C++, and that weakness is compounded by Rust’s strictness on coherence, the orphan rule, and lack of any duck typing.
Much more interesting and useful comparisons in the thread. But don’t go too deep or too far, or you will encounter the increasing amount of C++ bashing and Rust propaganda.
Consider this:
I also feel that people who just come to /r/cpp to advocate Rust are newcomers who completely fail to understand the purpose of Rust.
This pearl though, ugh:
You can smell the fear around here these days.
My eyes are stuck.
Circle: the next C++ compiler
It is absolutely insane to me that one guy has both made his own C++ compiler and has also added some awesome compiler extensions to the language like native shader compilation. ↑
A new Reddit post by Sean Baxter on Circle vs. C++ “successor languages”:
Circle’s feature pragmas let you select your own “evolver language.”
Having a facility to make source breaking changes so that the language can evolve: awesome. Having a knob for every feature so that everyone can design their own dialect of the language: pretty bad I think.
OTOH:
Works fine in other languages, here’s all the extensions you can enable per-source-file in ghc: https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/table.html; I never heard any haskeller around me complain about it.
Fighting words from Sean Baxter:
Would you rather have the features you want, or would you rather deny others the features they want?
We’re at an impasse in C++ because the standard for changing anything is consensus. This is [an] impossible in most cases. We should let institutional users, who sponsor tool development, lead the language in directions that they want it to go in.
Ah yes, institution-specific C++ versions, what could possibly go wrong there.
A redditor points out a pretty important detail:
But Circle is not open-source?
Another replies:
Unfortunately this is a killer. No company is going to want to use Circle to build millions of lines of source code when it can cease development at any time with no recourse.
Also there’s no Windows support, which is a showstopper for many people.
Cpp2 design notes
Will Carbon replace C++?
- Manuel Rubio
- Written as if Carbon is a language that’s available.
- HackerNews
- “Betteridge’s law holds up as usual” ↑
- Also many other comments expressing doubt
This comment:
And C++ just… doesn’t have that many real problems. It has a lot of irks, but the problems people run into are problems that others already solved, a thousand times, over the last half century, in many different ways for many different iterations of the language.
Pretending you can replace C++ is like pretending you can replace cars. Not just “create EVs” but straight up replace cars. Good luck, you won’t succeed if that’s your goal, so hopefully you realise you need to focus on making a decent language that some folks might consider using instead of C++ for some of their work, instead of creating “the successor to C++”.
Size Matters: An Exploration of Virtual Memory on iOS
On 64-bit Apple platforms, the entire 4 GiB 32-bit address space (addresses [0x00000000, 0xFFFFFFFF]) is not accessible by the process, which catches both NULL pointer dereference bugs and 64-bit to 32-bit pointer truncation bugs.
Visual Studio 2022 17.4
CMake debugger in Visual Studio
Build system configuration generator debugger lol ↑
Mastodon
Overheard from a program manager when talking about project status reporting:
“Watermelon status”
Green on the outside, but actually red on the inside.