> Sadly there is not a simple way to integrate this to native loop constructs without macros and even then it is a bit ugly.
I’ve implemented something like this before, without macros. It’s a little ugly, but not that bad IMO.
If you write a native range-based for loop:
for (auto foo : obj) { /* do something */ }
it essentially desugars to
auto it = foo.begin();
auto end = foo.end();
for (; it != end; ++it) {
auto foo = *it;
/* do something */
}
To make it work with a custom type, you need to implement `begin()` and `end()` methods, but the returned objects don’t need to support the full STL iterator protocol; they only need to support the exact sequence of operations from the desugaring. So, for example, `end()` can return a unique `End` type that contains no data and does nothing. `begin()` can return a different type that does all the real work and implements `operator!=(End)`. With that, it’s not too hard to implement a wrapper around a Python-like iterator protocol.
The main drawback is that you need to temporarily store each item in the begin object before it’s moved into the iteration variable. This is because you have to already know whether a next item exists at the point of `it != end`, but then the item isn’t actually retrieved until `*it`. The extra move has a slight cost, but the compiler can often optimize it away to nothing. You can also avoid this if the for loop uses a reference type (`for (auto& foo : obj)`).
112233 · 17h ago
(Since c++17)
The technique you so well describe in your comment does not work with the original range for :(
Not that it is an issue anymore, but I'd forgive anyone who tried to write code like this when range for was added from not trying anymore, because they remember the original semantics.
reads like a testimony in a negligence court case.
tubs · 14h ago
I think you can also define begin/end as non member functions (eg if you don’t own the code for the type).
tialaramex · 15h ago
> proof that the person saying that does not understand the C++ language. This was followed by several "I am a C++ standard library implementer and everyone I know calls it the STL". Things deteriorated from there.
It feels natural to assume that the implementers and long time WG21 members must understand the language, but this is not true. C++ spiralled well beyond the capability of a person to actually understand it years ago.
Maybe that's unfair, but it's unusual. This is a constructed language, its syntax and semantics matter greatly and yet in practice our grasp of its meaning is more akin to that for say, English, than for Perl or Rust.
There are contradictory style guides, people with well meant rules of thumb contradicted by a world of real usage, numerous dialects, not to mention people who strongly believe other users of the language are "doing it wrong" and yet what they're doing works fine.
Compare the C++ code samples with the Modern C++ usually talked about C++ conferences.
This is why I keep saying I only see such high bar code on conference slides, and my hobby projects, those DirectX code samples are much more closer to daily C++ written in big corporations, ironically even those that are C++ compiler vendors with seats at WG21.
On the other hand, there are many industries where I don't see Rust taking anything meaningful away from either C or C++, regardless of how much we complain about them, or how much better Rust happens to be over them.
jeroenhd · 14h ago
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.
pjmlp · 14h ago
That is an excuse, there are modern C++ ways to interact with COM, as shown in C++/WinRT DirectX samples, or using WIL.
In what way does interact with C APIs become an argument to use alloca() with raw pointers?
Just recently I also submitted an issue on Azure C++ SDK regarding use of C style strings and arrays, what is the excuse there?
Const-me · 12h ago
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.
pjmlp · 12h ago
Examples provide the foundation for learning, when the examples are bad, people learn bad practices.
account42 · 8h ago
I have never seen ATL used in production code but I have seen many "legacy" Win32 functions, including *A variants.
Const-me · 8h ago
That particular class doesn’t depend on the COM-related pieces of the ATL library. It can be used in any C++ project which targets windows desktop platform. I think since VS2015 ATL is available even in the freeware community edition of the IDE. Before that, it required a commercial edition.
About non-Unicode WinAPI functions, I don’t use them at all in the software I’m developing, nor the TCHAR conditional typedef. VC++ compiler defines wchar_t as a built-in type for the UTF16 strings used in WinAPI functions.
azhenley · 19h ago
> The post got linked by Hackernews and Reddit. As is usual the majority of comments did not talk about the actual content but instead were focused on two tangential things.
Too true, and this is too good. Start with part 1 (and the comments) if you haven’t.
ryandrake · 8h ago
I wonder what it is about the HN audience or about the HN voting system that seems to always result in this. You see this in so many stories posted here: Out of a 1000 word article, someone nitpicks a single phrase, and 75% of the comments rathole on that discussion rather than talking about the article.
steveklabnik · 6h ago
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.
account42 · 8h ago
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.
rzzzt · 16h ago
If you want to read the referenced comments, here they are (probably -- I don't have a crystal ball, only access to a search engine):
Obviously you can delete than iterate. He means delete while iterating.
OskarS · 7h ago
Ah, ok. But then: you kinda can't do that at all. You certainly shouldn't.
For unordered_map (and every hash table in the known universe) erasing anything invalidates all iterators, so you can't iterate while erasing. For std::map, you can if you're very, very careful (erasing invalidates the iterator you're currently on, but if you cache the next iterator, THEN erase the current one, it'll probably work, but be very fiddly). Most languages forbid this entirely: e.g. Rust's ownership model doesn't allow it, Python throws an exception, etc. It's just a very bad idea in general.
tom_ · 7h ago
Iterator-based std::unordered_map::erase and std::map::erase return a new iterator, one past the range erased, specifically so that you can erase while iterating. Along these untested lines:
There's an argument to be made that maybe you should do something else, but if you want to do the above, you can!
OskarS · 7h ago
Huh, TIL! I didn't realize that, I just always avoid this pattern because it's such a common source of bugs (and if I really need to, I just use the erase_if).
EDIT: just saw your example and checked cppreference, it says the return value "Iterator following the last removed element" for std::unordered_map. So i think you need to add an `it--` after your erase, otherwise it will "skip over" the next element. Right?
Also just read this little nugget on cppreference for unordered_map::erase:
> Removes specified elements from the container.The order of the remaining elements is preserved. (This makes it possible to erase individual elements while iterating through the container.)
This seems like a crazy guarantee to put in the standard, it must really limit the kinds of hash tables you can make that matches the unordered_map interface.
monkeyelite · 1h ago
> This seems like a crazy guarantee to put in the standard
It’s a great and useful guarantee.
> it must really limit the kinds of hash tables you can make that matches the unordered_map interface.
Many libraries treat containers as “abstract” with many possible implementations. STL explicitly does not. It’s a specific data structure from a computer science class.
incrudible · 13h ago
What is the use case for that? Seems more like a footgun, at least for a generic container interface.
simonask · 11h ago
Surely you must be kidding? Inserting/removing in a container while iterating through it is one of the all time greatest and most iconic bugs. People do it because they want to do it.
In reality, very few real-life containers can support this pattern, which is why this is a headline case for Rust, because it statically prevents this bug.
But yes, for removal the correct thing is always to use `std::erase_if` (C++) or `retain()` (Rust). For insertions, the only real solution is to build up a separate collection while iterating and then merging it into the original container when done. Yucky, but won't crash.
account42 · 8h ago
All containers can (at least theoretically) support modifying the container while iterating. You just have to adjust the iterator to take account for the changed container. C++'s std::map::erase(iterator) returns a new iterator for exactly this purpose - the iterator pointing to the next element before the operation but one that is still valid after the operation. Unfortunately you can't use it with range-based for loops even though they still use iterators under the hood but c'est la vie.
gpderetta · 12h ago
It happens surprisingly often.
monkeyelite · 9h ago
And if the library just did “python iterators” it would be impossible rather than difficult to remember.
jandrewrogers · 19h ago
I’ve said it many times: a pure C++20 standard library imagined from first principles with total disregard for legacy code would do amazing things for the reputation and value of C++ as a language. It could be so much better than it is.
Yes, I understand, compatibility. At some point, clean new code bases should not be burdened with that albatross.
jeroenhd · 15h ago
I like SerenityOS' "standard library". It has some Rust-like features (like ErrorOr, which is a lot like Result) but also some C++ usability enhancement that make use of modern C++ features rather than trying to force a C++-shaped peg into a POSIX-shaped hole. The only exception I know of is the pledge() implementation (which uses a space separated string rather than something like an array of enum values), but having pledge() at all is a pretty major improvement.
SerenityOS' original "make no use of external libraries" approach made one of the more complete re-imaginings of the C++ application landscape I've seen. It really changed my perspective on what C++ could be.
tyrellj · 7h ago
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.
The problem with C++ is not a bad standard library. It’s probably one of the best algorithms and containers libraries in any language.
platinumrad · 17h ago
<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.
TuxSH · 13h ago
Don't forget <tuple> not mandated to be trivial when it can be (and in fact never being trivial with GCC's stdlib), std::print performance issues (see P3107R5, P3235R3), etc.
Heck, even std::atomic was designed with only x64 in mind (it clearly shows), and is unusable outside it. One is incentivized to write their own "atomic" class until P3330R0 is approved for RMW-centric platforms ISAs like Aarch32 and Aarch64.
And of course, Rust already has "fetch_update"...
spacechild1 · 12h ago
> Heck, even std::atomic was designed with only x64 in mind (it clearly shows),
It certainly wasn't.
> and is unusable outside it
Total hyperbole. It's perfectly usable on ARM and other platforms.
P3330R0 looks a nice addition, though.
TuxSH · 10h ago
> It certainly wasn't.
The idiomatic way to do RMW (outside simple stuff like fetch-increment) with std::atomic maps 1:1 with x64 assembly and since fetch_update isn't provided, it's the only way to do it. It's way too close for comfort. See [1] for a comparison
> Total hyperbole. It's perfectly usable on ARM and other platforms.
It's not hyperbole. std::atomic is portable, but that's all it is.
std::atomic is about 30% to 40% (with outlined atomics on, which is the default) slower than handrolled asm (or custom reimplementations that provide fetch_update -- same thing). See [2] for a benchmark.
Yes, the design of std::atomic probably favors x64 in certain areas. However, you initially claimed that std::atomic has been designed with only x64 in mind. This is simply not true, which is easily proven by the fact that they explicitly support weak memory models.
> std::atomic is about 30% to 40% (with outlined atomics on, which is the default) slower than handrolled asm
Only for certain CAS operations. A 30% or 40% performance penalty doesn't sound too dramatic and certainly makes it "usable" in my book.
I appreciate your insight, but it could have been delivered with less hyperbole.
TuxSH · 8h ago
Apologies for the style of my previous messages.
> they explicitly support weak memory models.
Sure, but memory ordering is orthogonal to LL/SC vs CAS.
To me, fetch_update not being present from std::atomic's inception is major design oversight as CAS can be emulated via LL/SC but not the other way round.
Furthermore, fetch_update code is easy to read and less awkward to write than CAS loops (which currently are the only way std::atomic offers, and this is what I'm complaining about)
> Only for certain CAS operations. A 30% or 40% performance penalty doesn't sound too dramatic and certainly makes it "usable" in my book.
I disagree. Atomic variables (atomic instructions) are usually used to implement synchronization primitives, and are thus often meant to be used in very hot paths. 30% perf drops are actually quite bad, in that regard.
Of course if one is restricting themselves to using only member methods (fetch_add, fetch_or, etc.), then all is fine because these methods are optimized.
All in all, C++'s stdlib (the parts that aren't just __builtin wrappers, to be precise) is actually quite fine for most use-cases, like PC applications. Indeed, it is when one has latency constraints and/or severe memory constraints (e.g. < 512 KiB) that the stdlib feels like a hindrance.
spacechild1 · 7h ago
Thanks for the leveled response!
> Sure, but memory ordering is orthogonal to LL/SC vs CAS.
Sure, but your original claim was that std::atomic has been designed with only x64 in mind. That's what I meant to argue against.
I agree that the omission of something like fetch_update() has been an oversight and I hope that it will make it into the C++ standard!
As a side note, here's what the Rust docs say about fetch_update():
> This method is not magic; it is not provided by the hardware. It is implemented in terms of AtomicUsize::compare_exchange_weak, and suffers from the same drawbacks.
Looks like their (Rust) main motivator was readability. Whereas P3330R0 has that + performance on non-CAS hardware in mind. In any case, Rust's function could be optimized in the future, if they decide on it.
monkeyelite · 9h ago
I agree with that. But which language has better containers?
platinumrad · 7h ago
Boring answer, but Rust has better containers (and worse algorithms).
colejohnson66 · 4h ago
dotnet/C#?
Const-me · 13h ago
> 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.
account42 · 7h ago
Unicode is a moving target and not something that can be supported in a standard library that cares about long-term backwards compatibility. Every language that has added native Unicode support has suffered for it.
Fixed point types would be nice but can be implemented on your own and integers representing sufficiently small denominations (cents or fractions thereof) work in a pinch to deal with monetary amounts. And for the interface between libraries you will need to deal with things like currencies anyway and that goes well past the scope of a standard library.
Networking is also not something that is all that stable on the OS level beyond the basic socks API and you can just use that from C++ if you want to. There is no benefit from cloning the API into the C++ standard.
Same for filesystems - operating systems are different enough here that applications are better off handling the differences directly as can be seen in the unsatisfying attempt to abstract them in std::filesystem.
Pushing every functionality you can think of into the standard library is a mistake IMO. It should be reserved for truly ossified OS interfaces, basic vocabulary types and generic algorithms. Everything else is bloat that will be obsolete anyway sooner rather than later.
Const-me · 5h ago
> not something that can be supported in a standard library that cares about long-term backwards compatibility
Standard libraries of Java, JavaScript, and C# are counter-examples.
> you can just use that from C++ if you want to
Technically, C++ standard could feature an abstract interface for a stream of bytes. Would be useful not only for TCP sockets, also for files and pipes.
BTW I’ve been programming C++ for living for decades now, and I never saw production code to use C++ <iostream> header. Instead, C++ developers I worked with have been using either <cstdio> or OS-specific APIs.
> applications are better off handling the differences directly
Many other languages have managed to design high-level platform agnostic abstractions over these things, and implemented them in the standard libraries.
> reserved for truly ossified OS interfaces
By now this applies to files, file systems, pipes, and TCP sockets. While there’re some features hard to abstract away (examples include controlling file permissions, and probably asynchronous I/O), many real-world applications don’t need them. They just need basic stuff like read and write bytes from binary streams, concatenate paths, create/open/delete files, listen and accept TCP sockets.
112233 · 17h ago
What are you comparing it to? Because wow.
monkeyelite · 8h ago
Same question for you.
simonask · 10h ago
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.
account42 · 7h ago
> 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.
Those are the result of a constant stream of people complaining that the C++ standard library is bad because it doesn't contain their pet feature.
Needing additional dependencies beyond the standard library is not problem but how things should work. Because requirements differ and one persons useful dependency is another persons vestigial bloat.
simonask · 2h ago
You’re not wrong in principle, but I think it is absolutely fair to expect a standard library to include a good hash map implementation. These aren’t unreasonable demands.
The problem here isn’t that it’s bloated (I don’t particularly think it is), but that the things it provides are often very far from best in class.
jll29 · 18h ago
Compatibility is not a reason for not attempting to realize your proposal. (One just needs a difference namespace from "std" e.g. "lib".)
>The reason it caused the division at community is that the ones that you could not use both on the same project, this meant that for a while you had two "D" languages that were separate, libraries made with one did not worked with the other...
prydt · 16h ago
Have you seen libkj [1]? I've used it and really enjoy working with it. It has a rust-like owned pointer and the whole library uses these smart pointers.
It has proper container classes based on B-trees and its also got an async runtime.
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.
hoten · 18h ago
Could you give a couple examples?
krapht · 17h ago
Of libraries that are better than the STL? Or data structures that the STL is missing? Without getting into the weeds of esoteric data structures and algorithms I think there's a few holes that aren't addressed:
I’ve implemented something like this before, without macros. It’s a little ugly, but not that bad IMO.
If you write a native range-based for loop:
it essentially desugars to To make it work with a custom type, you need to implement `begin()` and `end()` methods, but the returned objects don’t need to support the full STL iterator protocol; they only need to support the exact sequence of operations from the desugaring. So, for example, `end()` can return a unique `End` type that contains no data and does nothing. `begin()` can return a different type that does all the real work and implements `operator!=(End)`. With that, it’s not too hard to implement a wrapper around a Python-like iterator protocol.The main drawback is that you need to temporarily store each item in the begin object before it’s moved into the iteration variable. This is because you have to already know whether a next item exists at the point of `it != end`, but then the item isn’t actually retrieved until `*it`. The extra move has a slight cost, but the compiler can often optimize it away to nothing. You can also avoid this if the for loop uses a reference type (`for (auto& foo : obj)`).
The technique you so well describe in your comment does not work with the original range for :(
Not that it is an issue anymore, but I'd forgive anyone who tried to write code like this when range for was added from not trying anymore, because they remember the original semantics.
The page: https://cppreference.com/w/cpp/language/range-for.html
reads like a testimony in a negligence court case.
It feels natural to assume that the implementers and long time WG21 members must understand the language, but this is not true. C++ spiralled well beyond the capability of a person to actually understand it years ago.
Maybe that's unfair, but it's unusual. This is a constructed language, its syntax and semantics matter greatly and yet in practice our grasp of its meaning is more akin to that for say, English, than for Perl or Rust.
There are contradictory style guides, people with well meant rules of thumb contradicted by a world of real usage, numerous dialects, not to mention people who strongly believe other users of the language are "doing it wrong" and yet what they're doing works fine.
https://devblogs.microsoft.com/directx/omm/
Compare the C++ code samples with the Modern C++ usually talked about C++ conferences.
This is why I keep saying I only see such high bar code on conference slides, and my hobby projects, those DirectX code samples are much more closer to daily C++ written in big corporations, ironically even those that are C++ compiler vendors with seats at WG21.
On the other hand, there are many industries where I don't see Rust taking anything meaningful away from either C or C++, regardless of how much we complain about them, or how much better Rust happens to be over them.
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.
In what way does interact with C APIs become an argument to use alloca() with raw pointers?
Just recently I also submitted an issue on Azure C++ SDK regarding use of C style strings and arrays, what is the excuse there?
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.
About non-Unicode WinAPI functions, I don’t use them at all in the software I’m developing, nor the TCHAR conditional typedef. VC++ compiler defines wchar_t as a built-in type for the UTF16 strings used in WinAPI functions.
Too true, and this is too good. Start with part 1 (and the comments) if you haven’t.
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.
- https://news.ycombinator.com/item?id=43468976
- https://www.reddit.com/r/programming/comments/1jjluxe/writin...
In C++ this is equivalent to an InputIterator.
For unordered_map (and every hash table in the known universe) erasing anything invalidates all iterators, so you can't iterate while erasing. For std::map, you can if you're very, very careful (erasing invalidates the iterator you're currently on, but if you cache the next iterator, THEN erase the current one, it'll probably work, but be very fiddly). Most languages forbid this entirely: e.g. Rust's ownership model doesn't allow it, Python throws an exception, etc. It's just a very bad idea in general.
EDIT: just saw your example and checked cppreference, it says the return value "Iterator following the last removed element" for std::unordered_map. So i think you need to add an `it--` after your erase, otherwise it will "skip over" the next element. Right?
Also just read this little nugget on cppreference for unordered_map::erase:
> Removes specified elements from the container.The order of the remaining elements is preserved. (This makes it possible to erase individual elements while iterating through the container.)
This seems like a crazy guarantee to put in the standard, it must really limit the kinds of hash tables you can make that matches the unordered_map interface.
It’s a great and useful guarantee.
> it must really limit the kinds of hash tables you can make that matches the unordered_map interface.
Many libraries treat containers as “abstract” with many possible implementations. STL explicitly does not. It’s a specific data structure from a computer science class.
In reality, very few real-life containers can support this pattern, which is why this is a headline case for Rust, because it statically prevents this bug.
But yes, for removal the correct thing is always to use `std::erase_if` (C++) or `retain()` (Rust). For insertions, the only real solution is to build up a separate collection while iterating and then merging it into the original container when done. Yucky, but won't crash.
Yes, I understand, compatibility. At some point, clean new code bases should not be burdened with that albatross.
SerenityOS' original "make no use of external libraries" approach made one of the more complete re-imaginings of the C++ application landscape I've seen. It really changed my perspective on what C++ could be.
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/...
Pretty much everything else (e.g. iostreams) is horrible.
Heck, even std::atomic was designed with only x64 in mind (it clearly shows), and is unusable outside it. One is incentivized to write their own "atomic" class until P3330R0 is approved for RMW-centric platforms ISAs like Aarch32 and Aarch64.
And of course, Rust already has "fetch_update"...
It certainly wasn't.
> and is unusable outside it
Total hyperbole. It's perfectly usable on ARM and other platforms.
P3330R0 looks a nice addition, though.
The idiomatic way to do RMW (outside simple stuff like fetch-increment) with std::atomic maps 1:1 with x64 assembly and since fetch_update isn't provided, it's the only way to do it. It's way too close for comfort. See [1] for a comparison
> Total hyperbole. It's perfectly usable on ARM and other platforms.
It's not hyperbole. std::atomic is portable, but that's all it is.
std::atomic is about 30% to 40% (with outlined atomics on, which is the default) slower than handrolled asm (or custom reimplementations that provide fetch_update -- same thing). See [2] for a benchmark.
[1] https://godbolt.org/z/EasxahTMP
[2] https://godbolt.org/z/Y9jvWbbWf
> std::atomic is about 30% to 40% (with outlined atomics on, which is the default) slower than handrolled asm
Only for certain CAS operations. A 30% or 40% performance penalty doesn't sound too dramatic and certainly makes it "usable" in my book.
I appreciate your insight, but it could have been delivered with less hyperbole.
> they explicitly support weak memory models.
Sure, but memory ordering is orthogonal to LL/SC vs CAS.
To me, fetch_update not being present from std::atomic's inception is major design oversight as CAS can be emulated via LL/SC but not the other way round.
Furthermore, fetch_update code is easy to read and less awkward to write than CAS loops (which currently are the only way std::atomic offers, and this is what I'm complaining about)
> Only for certain CAS operations. A 30% or 40% performance penalty doesn't sound too dramatic and certainly makes it "usable" in my book.
I disagree. Atomic variables (atomic instructions) are usually used to implement synchronization primitives, and are thus often meant to be used in very hot paths. 30% perf drops are actually quite bad, in that regard.
Of course if one is restricting themselves to using only member methods (fetch_add, fetch_or, etc.), then all is fine because these methods are optimized.
All in all, C++'s stdlib (the parts that aren't just __builtin wrappers, to be precise) is actually quite fine for most use-cases, like PC applications. Indeed, it is when one has latency constraints and/or severe memory constraints (e.g. < 512 KiB) that the stdlib feels like a hindrance.
> Sure, but memory ordering is orthogonal to LL/SC vs CAS.
Sure, but your original claim was that std::atomic has been designed with only x64 in mind. That's what I meant to argue against.
I agree that the omission of something like fetch_update() has been an oversight and I hope that it will make it into the C++ standard!
As a side note, here's what the Rust docs say about fetch_update():
> This method is not magic; it is not provided by the hardware. It is implemented in terms of AtomicUsize::compare_exchange_weak, and suffers from the same drawbacks.
https://doc.rust-lang.org/std/sync/atomic/struct.AtomicUsize...
So Rust's std::sync::atomic is equally "useless"? :)
Looks like their (Rust) main motivator was readability. Whereas P3330R0 has that + performance on non-CAS hardware in mind. In any case, Rust's function could be optimized in the future, if they decide on it.
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.
Fixed point types would be nice but can be implemented on your own and integers representing sufficiently small denominations (cents or fractions thereof) work in a pinch to deal with monetary amounts. And for the interface between libraries you will need to deal with things like currencies anyway and that goes well past the scope of a standard library.
Networking is also not something that is all that stable on the OS level beyond the basic socks API and you can just use that from C++ if you want to. There is no benefit from cloning the API into the C++ standard.
Same for filesystems - operating systems are different enough here that applications are better off handling the differences directly as can be seen in the unsatisfying attempt to abstract them in std::filesystem.
Pushing every functionality you can think of into the standard library is a mistake IMO. It should be reserved for truly ossified OS interfaces, basic vocabulary types and generic algorithms. Everything else is bloat that will be obsolete anyway sooner rather than later.
Standard libraries of Java, JavaScript, and C# are counter-examples.
> you can just use that from C++ if you want to
Technically, C++ standard could feature an abstract interface for a stream of bytes. Would be useful not only for TCP sockets, also for files and pipes.
BTW I’ve been programming C++ for living for decades now, and I never saw production code to use C++ <iostream> header. Instead, C++ developers I worked with have been using either <cstdio> or OS-specific APIs.
> applications are better off handling the differences directly
Many other languages have managed to design high-level platform agnostic abstractions over these things, and implemented them in the standard libraries.
> reserved for truly ossified OS interfaces
By now this applies to files, file systems, pipes, and TCP sockets. While there’re some features hard to abstract away (examples include controlling file permissions, and probably asynchronous I/O), many real-world applications don’t need them. They just need basic stuff like read and write bytes from binary streams, concatenate paths, create/open/delete files, listen and accept TCP sockets.
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.
Those are the result of a constant stream of people complaining that the C++ standard library is bad because it doesn't contain their pet feature.
Needing additional dependencies beyond the standard library is not problem but how things should work. Because requirements differ and one persons useful dependency is another persons vestigial bloat.
The problem here isn’t that it’s bloated (I don’t particularly think it is), but that the things it provides are often very far from best in class.
>The reason it caused the division at community is that the ones that you could not use both on the same project, this meant that for a while you had two "D" languages that were separate, libraries made with one did not worked with the other...
It has proper container classes based on B-trees and its also got an async runtime.
[1] https://github.com/capnproto/capnproto/blob/v2/kjdoc/index.m...
https://abseil.io
There are many good libraries out there, or fragments of libraries, but I’ve never found one that really scratches this itch.
https://github.com/martinus/unordered_dense provides better replacements for unordered_map/set.
The STL is missing B-trees and B-heaps, as well as d-heaps.
STL is also missing a radix sort, which is even more sorely missed now that we have std::executor::par_unseq to play with.