Writing your own C++ standard library part 2

Microsoft's DirectX C++ example code needs to interact with DirectX' C APIs. That will easily lead to "C with classes" C++ when most of the code is interacting with foreign APIs, like these API demos do.

I think open-source software like https://github.com/microsoft/WSL is probably more representative of what modern C++ companies look like. Plenty of files that just interact with OS C APIs, but no shortage of modern C++ features in use.

I would not call that example production quality code.

CreateFileA API thing is only available for compatibility with prehistoric software written for Win9x from the nineties. Also, the SDK comes with CAtlFile class which wraps CreateFileW / ReadFile / CloseHandle and guarantees closing handle in the destructor.

They are using a raw pointer in OMMSet structure which leaks memory. I would replace the raw pointer with std::unique_ptr<D3D12_RAYTRACING_OPACITY_MICROMAP_HISTOGRAM_ENTRY[]>

As for the _alloca, I think it’s OK however I usually assert() the size being allocated is reasonable, like under 256kb.

This is:

1. hilarious because it itself is an example of this behavior, we aren't discussing the article, but instead a tangent from a few words from it

2. an instance of Parkinson's Law of Triviality: it's just easier to respond to a comment than to read an entire article. Plus, many people read comments first to try and determine if an article is worth reading. So you end up with engagement in spinoff discussion, especially when the original is harder to read or understand to a general audience.

It's quite simple. These sites are frequented by humans how have their own interests and sometimes agendas rather than by automatons who only discuss what you personally want them to discuss. Hope that clears it up.

Both of these things are very easy to do in modern C++:

    // erase
    map.erase(2);

    // iterate
    for (auto &[k,v]: map) {
        // do stuff
    }

And if the library just did “python iterators” it would be impossible rather than difficult to remember.

I was curious, and a bit distractible this morning, so I took a look at their git repo. I did some osdev tinkering in college so I find this all interesting. AK seems to be their standard library that you were mentioning, but there's some interesting things going on in their Libraries dir too.

https://github.com/SerenityOS/serenity/blob/master/AK/ https://github.com/SerenityOS/serenity/blob/master/AK/Result... https://github.com/SerenityOS/serenity/tree/master/Userland/...

<algorithm> is a very good header, but most of the containers are substandard at best. `std::unordered_map` is required to be node-based, `std::map` can't be a B-tree, MSVC's implementation of `std::deque` is infamously a glorified `std::list`, and so on.

Pretty much everything else (e.g. iostreams) is horrible.

> probably one of the best algorithms and containers libraries in any language

Mostly agree about the algorithms. Another good thing in C++ are low-level mathematic parts of the standard library in <cmath> and <complex>.

Containers are OK, but neither usability nor performance are IMO great. Node-based containers like red-black trees and hash maps come with a contract which says pointers are stable, by default this means one malloc() per element, this is slow.

However, there’re large areas where C++ standard library is lacking.

File I/O is questionable to say the least. Networking support is missing. Unicode support is missing, <codecvt> deprecated in C++17 because they found out it no longer implements current Unicode standard and instead of fixing the standard library they dropped the support. Date and calendars support only arrived in C++/20. No built-in way to represent money amount, e.g. C# standard library has fixed-size 16 bytes type for decimal floating-point numbers, Java standard library has arbitrary-precision integers and decimals.

What are you comparing it to? Because wow.

The problem with C++ is not _just_ a bad standard library, but it's also that. There's a lot of "don't use this", including iostreams, std::regex, std::unordered_map, std::variant, and more. Not to mention vestigial parts of failed designs, like std::initializer_list.

Every serious C++ project worth its salt includes additional dependencies to patch it up, and it looks like that will be the case in perpetuity, because these problems are unfixable in the holy name of ABI stability.

Don't get me wrong, ABI stability is a worthy goal. The committee should just have realized that the current approach to it is untenable. The result is a very half-baked situation where ABI stability is not technically guaranteed, but nothing can be fixed because of it.

What a mess.

Rust takes a much, much more cautious approach (because of C++'s history), including explicitly not supporting Rust-native ABI stability and flat out discouraging dynamic linking. Also not very great, but it's sensible as long as there are no clearly superior solutions.

Not even close, and I am a fan of abseil. The design of abseil has legacy constraints that don’t need to apply to a C++20 clean room implementation. I have better re-implementations of abseil components in my own “standard” library simply because I didn’t have those constraints.

There are many good libraries out there, or fragments of libraries, but I’ve never found one that really scratches this itch.