STX – C++17 and C++ 20 error-handling and utility extensions(lamarrr.github.io) |
STX – C++17 and C++ 20 error-handling and utility extensions(lamarrr.github.io) |
The drawback I see of using a third-party solution for this is interoperability with other libraries. Rust's Optional and Result are especially great because they are part of the standard library, thus almost every project uses the same Result type. No need to define conversion operators.
They're part of Rust's core library. So they're available even when the full standard library isn't. Indeed core::option::Option is in effect a Lang Item, library components which are required to exist by the Rust language itself, as somebody pointed out to me on HN previously (technically Some and None are Lang Items, but well, they need to be the same type, so while an imaginary Rust implementation could name it Maybe or something instead of Option, that type needs to exist or the language can't happen at all)
C++ freestanding a) is barely supported, it's completely normal for a compiler vendor, e.g. Microsoft, to just decide they will not offer this at all and b) full of holes, so e.g. std::optional isn't provided in the freestanding library.
As a result, there isn't this same ubiquity in C++ for low level work. The language's built in types are garbage, and most of the standard library isn't available. Historically you had no choice, it's this rubbish or nothing, but Rust and to some extent Zig make that no longer true for a gradually increasing range of targets. Some C++ people have woken up and tried to improve freestanding because "We're terrible but there's no other choice" stops being a good sales pitch once your users have other Options. So I expect C++ 26 freestanding will be more useful and perhaps even better supported, for whatever that's worth.
The documentation seems nice as well...except I can't seem to find a link to the code itself. I have to believe it's right in front of me and I'm just not seeing it.
it's just a small wrapper around absl. Overal, the library just seems to reimplement or wrap a lot of stuff for no apparent reason
you aren't crazy, I also thought it was very weird that there weren't any links
The C++ standard library already exposes a std::optional type. Does this stx::Option type differ from that one?
std::optional is a stack pointer, like other C++ pointers you can straight up deref’ it and get an UB.
It looks like stx::Option is an actually option type, it focuses on safety and will throw if “unsafe” methods are called on the wrong state. It also provides a slew of monadic operators to operate over values.
I haven’t looked at the code but the stx documentation said it doesn’t use exceptions.
They explain it there: "No RTTI, memory allocation, nor exceptions."
Basically, nothing that has significant "runtime" cost....dynamic_cast, new/malloc, throwing exceptions.
In C++ this makes less sense because their standard library does have a defined "freestanding" subset but it doesn't make a very coherent whole, it's roughly the bits that seemed obviously to just not need any other components to work. It changes from version to version. And this stx library replaces what you might think of as core ideas, like an optional type, so you don't keep the shared vocabulary benefit.
[Edited to correct "standalone" to "freestanding"]
I'd always assumed rust may have taken this from C compiler arguments like -nostdlib / -nostdinc (and corresponding C++ ones -nostdlib++, -nostdinc++).
This is a bit misleading. It's easier to provide mutual exclusion on bare hardware than in an OS; just do a spinlock, except with modern ISAs the core doesn't even spin.
Presumably core doesn't offer this because it's a massive footgun for devs new to multithreading who would not understand why this is unacceptable to use in an OS-hosted process.
Although tricks like PAUSE are much cheaper than a naive spinlock, they are still spinning as I understand it, just not as frantically because that's pointless and wasteful.
I'm talking about wfi, wfe, and friends.
Ideally, a sufficiently smart compiler would be able to see code like
if (auto t = get_optional())
{
do_something(*t);
}
As another example, imagine if span was a language feature. A compiler could bounds check at compile time, and fully elide the checks at runtime in many scenarios (like in a loop over the span).
The entire point of optional is that you can swap it in for a raw or unique pointer and it'll be cheaper because no allocation. That's not the use case for an option type.
Also, in an ideal world, stdlib implementations would support error-checking for `std::optional::operator*`. "Undefined behavior" just means the standard doesn't specify what should happen. Both "let's use it for unsafe optimizations" and "trigger assertion failures" are valid implementions of undefined behavior, and a good implemention should allow the user to make this choice. For gcc, see -D_GLIBCXX_ASSERTIONS. Though I'll say that it's unfortunate that C++ implementations tend to default to "unsafe optimizations" and that the opt-in to safety is not standardized.