C++: "model of the hardware" vs. "model of the compiler" (2018)
ithare.com
ithare.com
I think in the end it's just another story of a C++ veteran living through the inevitable Modern C++ trauma and divorce ;)
(I wonder what he's up to today, ITHare was quite popular in game dev circles in the 2010s for his multiplayer networking blog posts and books)
They are, they are extensively used by software like ScyllaDB which itself is used by stuff like Discord, BlueSky, Comcast, etc.
C++ coroutines and "stackless coroutines" in general are just compiler-generated FSMs. As for allocation, you can override operator new for the promise types and that operator new gets forwarded the coroutine's function arguments
Rust gets it right, but has its own warts, especially if you're coming from async in a GC world. But there's no allocation; Futures are composable value types.
It is the same principle that drives languages like Rust in regards to being safe by default, in theory stuff like bounds checks cause a performance hit, in practice compilers are written to elide as much as possible.
C++ coroutines are so lightweight and customizable (for good and ill), that in 2018 Gor Nishanov did a presentation where he scheduled binary searches around cache prefetching using coroutines. And yes, he modified the allocation behavior, though he said it only resulted in a modest improvement on performance.
I wouldn't say that applies to everybody. I use C++ because it interfaces with the system libraries on every platform, because it has class-based inheritance (like Java and C#, unlike Rust and Zig) and because it compiles to native code without an external runtime. I don't care to much about allocations.
For me the biggest fumble is that C++ provides the async framework, but no actual async stdlib (file io and networking). It took a while for options to be available, and while eg Asio works nicely it is crazily over engineered in places.
Zig, is really Modula-2 in C's cloathing, I don't like the kind of handmade culture that has around it, and its way of dealing with use after free I can also get in C and C++, for the last thirty years, it is a matter of actually learning the tooling.
Thus C++ it is, for anything that isn't can't be taken over by a compiled managed language.
I would like to use D more, but it seems to have lost its opportunity window, although NASA is now using it, so who knows.
void *operator new(std::size_t sz, Foo &foo, Bar &bar) { return foo.m_Buffer; /* should be std::max_align_t-aligned \*/ }
I say this as someone that is not a fan of the stackess coroutines in general, and the C++ solution in particular.
Hence why anyone that has done low level .NET async/await code with awaitables and magic peoples, will fell right at home in C++ co-routines.
Anyone using WinAppSDK with C++ will eventually make use of them.
- Alan Perlis, Epigrams on Programming
That must be why builds today take just as long as in the 1990s, to produce a program that makes people wait just as long as in the 1990s, despite the hardware being thousands of times faster ;)
In reality, people just throw more work at the compiler until build times become "unbearable", and optimize their code only until it feels "fast enough". These limits of "unbearable" and "fast enough" are built into humans and don't change in a couple of decades.
Or as the ancient saying goes: "Software is a gas; it expands to fill its container."
- put each class into its own header/source file pair (a great way to explode your build times!)
- generally replace all raw pointers with shared_ptr or unique_ptr
- general software patterns like model-view-controller, a great way to turn a handful lines of code into dozens of files with hundreds of lines each
- use exceptions for error handling (although these days this is widely considered a bad idea, but it wasn't always)
- always prefer the C++ stdlib over self-rolled solutions
- etc etc etc...
It's been a while since I closely followed modern C++ development, so I'm sure there are a couple of new ones, and some which have fallen out of fashion.
Is that really sufficient to explode build times on its own? Especially if you're just using the more basic C++ features (no template (ab)use in particular).
Meanwhile the C builds done in UNIX workstations (Aix, Solaris, HP-UX) for our applications back in 2000, were taking about 1 hour per deployment target, hardly blazing fast.
Only if you fail to use binary libraries in the process.
Apparently folks like to explode build times with header only libraries nowadays, as if C and C++ were scripting languages.
> - generally replace all raw pointers with shared_ptr or unique_ptr
Some folks care about safety.
I have written C applications with handles, doing two way conversions between pointers and handles, and I am not talking about Windows 16 memory model.
> - general software patterns like model-view-controller, a great way to turn a handful lines of code into dozens of files with hundreds of lines each
I am old enough to have used Yourdon Structured Method in C applications
> - use exceptions for error handling (although these days this is widely considered a bad idea, but it wasn't always)
Forced return code checks with automatic stack unwinding are still exceptions, even if they look differently.
Also what about setjmp()/longjmp() all over the place?
> - always prefer the C++ stdlib over self-rolled solutions
Overconfidence that everyone knows better than people paid to write compilers usually turns out bad, unless they are actually top developers.
There are plenty of modern best practices for C as well, that is how we try to avoid making a mess out of people think being a portable assembler, and industries rely on MISRA, ISO 26262, and similar for that matter.
When you decouple the language from the hardware and you don't specify an abstraction model (like java vm do), "the platform" is just whatever the implementer feels like at that moment.
Endianness will be with us for a while, but modern languages don't really need to consider the other factors, so they can take significant liberties in their design that match the developer's intuition more precisely.
Basic compile time constant folding also isn't anything modern, even the most primitive 8-bit assemblers of the 1980s allowed to write macros and expressions which were evaluated at compile time - and that gets you maybe 80% to the much more impressive constant folding over deep callstacks that modern compilers are capable of (e.g. what's commonly known as 'zero cost abstraction').