Three new utility functions in C++23

https://mariusbancila.ro/blog/2022/11/08/three-new-utility-functions-in-cpp23/

by todsacerdoti • 4 years ago

139 187 4 years ago

mariusbancila.ro

secondcoming2• 4 years ago

They missed a trick with `std::to_underlying`. It should work on all types, not just enums.

By not doing that you still have to do `std::is_enum_v<T>` somewhere.

For types that aren't enums it should do nothing (maybe `std::identity`)

fluoridation6• 4 years ago

Seems easy enough to add your own overloaded function that does that. But then again, std::to_underlying() doesn't do much to begin with; it just casts to std::underlying_type<T>::type.

hoseja• 4 years ago

Network protocols specify big endian for the order of transmission

Only in the parts specified by the protocol (headers etc). I encourage everyone sending data over network in a novel way to just use little-endian.

halayli• 4 years ago

That's not a good advice. Only if the sender and receiver are guaranteed to be running on little endian architecture you can make such a claim. A better advice is to always consider the endian-ness when designing protocols and have a strategy to handle it.

dontlaugh• 4 years ago

I think they mean for any new protocol, defining it as little-endian.

patrec2• 4 years ago

How is that "better advice"? Big endian architectures are pretty much dead (x86, ARM and RiscV are all little endian; some ARM chips are bi-endian, but not Apple's) and there's no discernible compelling advantage that would allow a comeback. You absolutely want to specify the byte order in new protocols as little endian.

overgard• 4 years ago

There are practically no big endian architectures anymore. Little endian is a sensible default. The weird architectures should bare the burden of complexity.

elteto• 4 years ago

That’s just a waste of cycles on encoding and decoding, as most/all senders and receivers are LE nowadays.

stinos• 4 years ago

I love how over the past decade my own C++ utility library has been continuously shrinking because with each update there are more and more utility functions (like the to_underlying this article mentions) and even complete libraries (like <filesystem>) which replace self-written or 3rd party code.

gpderetta23• 4 years ago

I always worry as much as anyone else on each new release for the additional complexity ("the committee is out of control!!!!1!!eleven!"), but on each compiler upgrade when I actually get to use the new versions of the standard I'm always pleasantly surprised about all the little low-key quality of life improvements.

einpoklum2• 4 years ago

While that's true, when you get to a point where you have to write a small library - so that you need to cater to all of the language and standard additions - that's when you start experiencing pain. How do I expose the right iterators and sentinels? What do I have to specialize? Do I need to define concepts? Do I need to use concepts from elsewhere? I am often at a loss...

yrro2• 4 years ago

Hmm. How often do people actaully want to std::byteswap as opposed to "convert this value from native byte order to big-endian" or "convert this value from little-endian to native byte order"?

i.e., the functions documented in https://man7.org/linux/man-pages/man3/endian.3.html (why oh why are they not also documented in the GNU C Library Manual...)

Karellen• 4 years ago

Yeah, for portable code you also need a function to tell you if you're on an architecture where you need to do a byteswap for the data you have. e.g. you know you have data in little-endian format - do you need to swap it to work with it natively? That depends.

Maybe having something like convert_be() and convert_le(), one of which is a no-op and the other does the byteswap (depending on your arch) would be better. It removes the duplication of e.g. htobe() and betoh() which are exactly the same function, while allowing the caller to not worry about which architecture their code is compiled on.

apaprocki5• 4 years ago

I view it more as a platform-independent building block to be used by library authors. For instance, here's our suite of byte order macros that this will not simply replace:

https://bloomberg.github.io/bde-resources/doxygen/bde_api_pr...

yrro2• 4 years ago

Huh. You know I had never considered why we have htobe32 and be32toh which do exactly the same thing. Maybe because of oddball architectures which are neither big nor little endian?

For instance... /usr/include/x86_64-linux-gnu/bits/endian.h has:

#define __LITTLE_ENDIAN 1234 #define __BIG_ENDIAN 4321 #define __PDP_ENDIAN 3412

Apparently this is called 'middle-endian'... yikes!

On the other hand I sort of like having one function that's clearly used for importing values to the host's byte order, and another for exporting values from the host's byte order. But maybe that's just because I'm used to having them...

beached_whale2• 4 years ago

Those are in <bit> as of c++20

Findecanor2• 4 years ago

I've always thought that it should have been possible in C and C++ to declare endian-ness as the property of a member variable's type, and that's it: the compiler would then automatically choose where to swap the byte-order to/from he native byte order.

The benefits are obvious: Code is declarative, and there's no risk of a bug where you missed to call std::byteswap() or did it twice.

Also, the compiler could automatically extract and insert values from/to little-endian and big-endian bitfields (which can be a handful...), and it could optimise to reduce the number of byteswaps in the code.

kllrnohj3• 4 years ago

Sounds like a pretty easy class you could write in C++. Template it for anything that's integral if you want to get fancy so you can do BigEndian<int32_t> or BigEndian<int64_t> and provide operators that convert to/from the "native" type transparently.

Is that generically useful enough to be part of the C++ standard? Seems like the type of thing that more belongs in a helper utility (aka, surely something like Boost already has this)

CJefferson2• 4 years ago

I understand why it's there, but I do find it fun that when many people are trying to reduce undefined behaviour in their code, std::unreachable is literally defined as "this is undefined behaviour, use that to optimise".

I suspect 99.9% of uses of std::unreachable would be better replaced by abort. (There will be those times when the code is correct and the optimisation gains are worth it -- but they will be rare).

actionfromafar3• 4 years ago

+100

I felt physically ill when I read:

It’s intended to be used when you know you have an execution path in your code that cannot be reached but the compiler cannot figure that out.

It felt like saying to the compiler, "please, find a way to make my program break even more easily". Exactly not what I need.

gpderetta23• 4 years ago

You might not need it, but gcc/clang have __builtin_unreachable and msvc has __assume and both are used extensively for optimizations. std::unreachable is just standardizing existing diverging practice.

fluoridation6• 4 years ago

If a code path that's supposed to be unreachable is reached then the program is already broken. Unless it has a bug, a compiler will not make a program more broken. At worst (or best, depending on how you look at it) it will only make any bugs it already has more obvious.

apaprocki5• 4 years ago

One thing people are missing is that you may need to use this to satisfy conditions that the compiler might encounter to emit a warning (or error if equivalent of -Werror is enabled). If you have strict warnings on, but no way to tell the compiler that a location should not be reachable, you wind up in situations where you are doing something like `assert(!"not reached!")` and it won't be enabled in all build types. This is similar to how `__attribute__((noreturn))` is used in a "fatal" function that isn't always enabled but needs to convey its intention to static analyzers so that they stop evaluating branches past that call.

suyjuris• 4 years ago

You can compromise by using abort in debug builds and std::unreachable in release builds.

apaprocki5• 4 years ago

The point of this is that you can control that behavior at the compiler level using different flags instead of changing the code itself (via preprocessor defines).

JonChesterfield• 4 years ago

I love it when switching debug mode on changes the control flow graph of my program. Keeps life interesting.

pif• 4 years ago

Then just use abort!

flohofwoe2• 4 years ago

It's been useful to me in one very specific place so far: to remove a range-check in front of the jump-table lookup in a big switch-case statement. For 'very hot' code paths like in the instruction decoder of an emulator or interpreting byte-code VM this might actually translate to a measurable difference.

In debug mode it makes a lot of sense to replace the __builtin_unreachable with an abort() though.

usefulcat• 4 years ago

this is undefined behaviour, use that to optimise

Optimization is a very large part of the reason for having undefined behavior at all. Viewed from that perspective, I don’t see how the existence of std::unreachable is at all odd. Also, it’s not like anyone is required to use it.

ho_schi• 4 years ago

https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-langu...

The rational is better explained there :)

Most programmers will write an error message and halt execution flow (return EXIT_FAILURE, abort(), exit() or even an exception). The hint about assembler give cares about special (maybe optimized or machine specific) code or embedded stuff. And the second example refers explicitly to functions which do exit() and never return actually. The committee tidies up stuff. Something which compilers provide individually is becoming standard.

XCSme7• 4 years ago

Why is it called "byteswap" and not "bytereverse"? "Swapping" can be done in any number of ways, but only one way to reverse.

siknad• 4 years ago

Reversing bytes sounds like reversing their bit orders to me.

fluoridation6• 4 years ago

Could be called "byte-wise reverse".

XCSme7• 4 years ago

That would be "bitreverse" I guess, plus their description of byteswap[0] is exactly that:

"Reverses the bytes in the given integer value n."

I would expect the description for "byteswap" to be something like "swaps the given bytes of an integer value n." and be called like byteswap(x, a, b), where a and b are the indicies of the bytes to be swapped.

[0] https://en.cppreference.com/w/cpp/numeric/byteswap

secondcoming2• 4 years ago

There's an x64 instruction called BSWAP.

pm215• 4 years ago

I don't know, but 'swap' seems to have become the standard term for the operation, used in places like the C bswap family of functions and the x86 'bswap' instruction. My (totally unsupported and unresearched) guess is that it became popular as a term when 16-bit architectures were common -- "swap the bytes in a 16 bit value" is unambiguous.

The Arm architecture does call this operation "reverse bytes", though, so it's not universal to call it "swap".

XCSme7• 4 years ago

That makes sense.

Koshkin5• 4 years ago

Because the reversal is done by swapping the first byte with the last, etc.

XCSme7• 4 years ago

But on the same note, sorting is also done by swapping elements.

a28002764• 4 years ago

My first impression is that all three of these are clutter to an already very cluttered language ...

1.) Coming from embedded programming, I can see the utility of `std::unreachable`. But shouldn't this be a compiler directive? Or a standardized #pragma? Can someone more knowledgeable in C++ say whether using functions as markers is a common mechanism in std:: ?

2.)Maybe the example is bad here, as it doesn't even save typing. (18 chars for `std::to_underlying` vs. 16 for `static_cast<int>`. The 'old' variant seems more expressive to boot. If anything, how about `static_cast<auto>`? or <underlying> ...

3.) The usefulness of `std::byteswap` to convert data to network byte order seems trivial vs. the venerable old `htonl` family of functions. `std::byteswap` seems more like intrinsics meant to expose possibly present target machine instructions to the user. Like `std::unreachable` this is probably of most use to embedded / low-level programming. This may be a deficiency in the article...

If it's not obvious, I'm not a big C++ fan and read the article with C-tinted glasses :)

flohofwoe2• 4 years ago

...`std::unreachable`. But shouldn't this be a compiler directive?

Probably "committee pragmatism", a stdlib change might be easier to get approved than a language change, and compilers already have builtins for this, they're just not compatible (but the differences can be wrapped in a macro, and since C++ doesn't like to expose macros, it's probably still a macro, but hidden inside a stdlib template).

FWIW it looks like C23 will also just get a macro:

https://thephd.dev/ever-closer-c23-improvements#unreachable-...

gpderetta23• 4 years ago

Also from a standardization point of view there isn't really much of a difference between a builtin and a plain library function. Library functions can be scoped in namespaces and that's a plus.

addaon6• 4 years ago

std::unreachable() feels like it's what std::assert(false) should be, except that std::assert(false) is bizarrely defined (as a no-op) when NDEBUG is defined. This is one of those strange cases where the spec defines behavior that I'd strongly expect to be undefined.

pjscott• 4 years ago

I checked LLVM's libc++ source, and it's an inline void function defined in a header, which contains only a call to __builtin_unreachable() when available or std::abort() otherwise.

chrisseaton4• 4 years ago

Is there syntax available in C++ to write some kind of instruction to the compiler which is not some kind of call? Even __builtin_trap is a call isn't it? What else could you attach a directive to?

tlb2• 4 years ago

Directives are attached to functions, like abort() has the [[noreturn]] attribute, so compilers don't have to emit any code that would run after it returns, or save anything on the stack.

std::unreachable() goes a step further, and tells the compiler that it doesn't even have to emit the call instructions or any instructions leading up to it.

Karliss2• 4 years ago

c++11 style attribute. There are already similar attributes [[unlikely]] and [[likely]] which can be attached to any statement. Having [[unreachable]] wouldn't be that surprising. C++23 also introduced [[assume(expr)]] which is basically conditional unreachable. I don't see a reason why standard committee couldn't have defined that [[assume(false)]] can be used for that purpose instead of new builtin. Either of the two would have been more consistent in my opinion, only reason I see for choosing a builtin function is because GCC and Clang already had __builtin_unreachable() builtin functions, so making it a function might in theory reduce the work for them.

planede2• 4 years ago

1.) Functions are fine for this stuff. The compiler can be trusted for its ability to "inline" the language-level `__builtin_unreachable()` or equivalent at the relevant optimization levels.

2.) static_cast<int> is shorter, if you know that the underlying type is int. But even if you know, you might not want to spell out int, to be more robust to code changes, which might involve a change of the underlying type of the corresponding enum.

In generic context you might not even know the underlying type.

3.) I absolutely agree. I think it was a mistake to include. The included `std::byteswap` can be expressed in terms of `std::ranges::reverse(std::as_writable_bytes(obj))`. It could be quality of implementation detail to get a bswap instruction from the latter.

I would be happy with equivalents of the `htonl` functions in the standard library, but I have strong opinions of the appropriate function signatures of it for C++.

a28002764• 4 years ago

2.) static_cast<int> is shorter, if you know that the underlying type is int. But even if you know, you might not want to spell out int, to be more robust to code changes, which might involve a change of the underlying type of the corresponding enum.
In generic context you might not even know the underlying type.

Thanks for pointing this out! I'm aware that the underlying type of an enum isn't always `int`. This is what I meant by saying the `static_cast` feels more expressive to me, i.e. reading the code, at least I'll now on sight what type is being used here. I'd probably have to 'let go' more to effectively use CPP, but this category of mechanism to cope with a generic/type system so complicated that I can't figure out the type of anything anymore. In the same vein, 'making code more robust to changes' feels like kicking the can down the road (to me). At some point you'll need to deal with the actual type ...

gpderetta23• 4 years ago

Re 3), all the <bits> instructions can be expressed in high level code, and compilers have been able to convert high level code to the actual machine instructions for a while.

The issue is exactly which code pattern is detected by which compiler varies a lot, so to avoid having to rely on that there was a strong push to add all these explicit intrinsics. Also std::bytesewap is more readable than the longer reverse+as_writeable_bytes.

s28l5• 4 years ago

1. It is a compiler defined function (`__builtin_unreachable()`), but the issue is that MSVC doesn't have it, so you need a different implementation per compiler [0]. Plus, if a new compiler shows up (besides MSVC/GCC/LLVM), you'd need to investigate what the correct way to express `__builtin_unreachable` is.

From a compiler perspective, using a function makes the most sense, since that fits into the existing control-flow analysis that the compiler will do. Pragmas are processed by the pre-processor, so they aren't appropriate for expressing control flow hints.

2. `std::to_underlying(t)` is a wrapper around `static_cast<std::underlying_type_t<std::remove_cv_t<std::remove_reference_t<decltype(t)>>>>(t)`. So a lot fewer characters. It's also useful since `std::underlying_type_t<T>` behaves weirdly if `T` is not an enum type.

I think you are maybe missing the context that C++ allows the representation of an enum to be defined, e.g. `enum class X : unsigned char {};` vs `enum class Y : unsigned long long {};`. So you can't always cast to `int`. Technically, this isn't the case in C either: the type defaults to `int`, but the compiler will pick a larger type if necessary, e.g. `enum Z { a = ((long long)INT_MAX) + 1 };`

3. `htonl` are not standardized, so they were not part of the C++ standard library. Also, on Windows, I believe you'd need to include `winsock.h` to get access to them, which has its own idiosyncratic issues. You are also missing the context of C++ defining operator overloading, so you can call `std::byteswap(0ull)` and get an `unsigned long long` and you can call `std::byteswap(std::uint16_t{0})` and get a 16 bit unsigned integer.

[0] https://stackoverflow.com/questions/60802864/emulating-gccs-...

a28002764• 4 years ago

3. `htonl` are not standardized, so they were not part of the C++ standard library.

I was questioning the motivation of this to facilitate network-byte-order issues as stated in the blog post. The proposal[1] (that the post linked to) also confirmed that the motivation was to expose more machine code intrinsics rather than deal with network byte order like I expected.

Concerning 1.) yeah, I guess I'd prefer a #pragma aesthetically, but didn't think about the fact that it wouldn't be exposed to the compiler.

Thanks for the well thought out reply!

[1] https://isocpp.org/files/papers/P1272R4.html#motivation

amluto• 4 years ago

You are also missing the context of C++ defining operator overloading, so you can call `std::byteswap(0ull)` and get an `unsigned long long` and you can call `std::byteswap(std::uint16_t{0})` and get a 16 bit unsigned integer.

I can believe this is useful in explicitly-typed form, i.e. using std::byteswap<T> with T specified. But letting T be inferred seems quite dangerous: C++ loves changing integer types around all by itself (via type promotion, for example), and byteswap<int> and byteswap<long> are (on UNIXy systems) simply not the same operation. For that matter, byteswap should really only be used on uintN_t.

byteswap(a+b) is just asking for trouble.

pjmlp3• 4 years ago

Plus, if a new compiler shows up (besides MSVC/GCC/LLVM)

They are still far from being the only game in town.

Karliss2• 4 years ago

Pragmas are processed by the pre-processor

This is wrong a lot of pragmas, I would even say most pragmas are not handled by preprocessor. Some examples: pragma pack, warning control, pragma GCC unroll, per function optimization setting changes, all the pragmas which 1:1 map to c++11 style attributes. None of that is handled by preprocessor, pragma once seems like rare one which is. Yes all of them are compiler specific, but handling compiler specific behavior is one of the main purpose of pragmas.

simplotek2• 4 years ago

Pragmas are processed by the pre-processor, so they aren't appropriate for expressing control flow hints.

I don't thing this is remotely true. C++ pragmas were designed with the express purpose of providing additional information to compilers.

cesarb• 4 years ago

`htonl` are not standardized

They are: https://pubs.opengroup.org/onlinepubs/9699919799/functions/h...

jcelerier• 4 years ago

Technically, this isn't the case in C either: the type defaults to `int`, but the compiler will pick a larger type if necessary, e.g. `enum Z { a = ((long long)INT_MAX) + 1 };`

if you read this and alarm bells didn't ring in your head I really invite you to immediately go check any enum you may have defined in your code because this is absolutely false with MSVC in C++ (https://gcc.godbolt.org/z/6bqW9rE81) (and C is often compiled as C++ on windows)

lelanthran• 4 years ago

From a compiler perspective, using a function makes the most sense, since that fits into the existing control-flow analysis that the compiler will do. Pragmas are processed by the pre-processor, so they aren't appropriate for expressing control flow hints.

This seems par for the course for all C++ stuff: it's designed from a compiler perspective, not from a programmer perspective.

The correct way, IMHO, is to design features that supports the user's workflow, not to design the same feature in a way to make the compiler's job easier.

`htonl` are not standardized, so they were not part of the C++ standard library.

They're POSIX standardised. The decision should have been to adopt something that exists in an existing and widespread standard rather than the worrisome not-invented-here syndrome that I see here.

colanderman2• 4 years ago

Longtime C, C++, and embedded programmer here.

1. Why "should" it be something different? It is semantically part of code flow; making it a pragma breaks that model. This replaces the nonstandard __builtin_unreachable().

2. This doesn't exist to save typing. static_cast<auto> doesn't make sense to me (that reads like a no-op). static_cast<underlying> introduces a new reserved word which is a big no-no.

3. This is not the same as htonl, which only does anything on little-endian machines. (htonl is also a POSIX function, not a C++ function.)

lvass• 4 years ago

1. Isn't std inadequate in "embedded" programming?

taylorius• 4 years ago

I definitely agree with 1. I find the inclusion of core language features in std:: to be rather disconcerting. I've always thought of std:: as a set of standard useful library functions, separate from actual language features.

kllrnohj3• 4 years ago

That's what it is. It's a useful utility function over non standard compiler built-ins.

The alternative would be a new keyword, but then the go-to complaint would just be about c++ keyword bloat and source compat regressions

kazinator2• 4 years ago

But shouldn't this be a compiler directive?

Lisp perspective: anything that can be a function almost certainly should be a function (and not a special operator or macro).

std::unreachable() does not have any arguments; therefore it doesn't need any special argument evaluation semantics that would require a compiler built-in.

The way C and C++ work, compiler directives are keywords and not identifiers. Keywords are not namespaced. Introducing a keyword called "unreachable" is problematic; far more so than a new element in the std namespace.

My only problem with std::unreachable is that I would never use it over std::abort.

Nobody needs a function whose only job is to invoke undefined behavior (from which it is then assumed that it is not reached).

It's a good cold day, so I can almost hear the Rust people laughing in the distance.

steveklabnik• 4 years ago

To be clear, Rust has this exact same functionality, with an intrinsic as well as a regular function that wraps said intrinsic.

The only difference is that it’s marked unsafe.

https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....

There is a safe version that is just a wrapper around panic! with a standardized message.

nynx2• 4 years ago

Why on earth are these in C++23 and not C++11? There are a ton of things that should’ve been standardized over a decade ago but only show up in C++20 or later. `std::span<T>` is a huge one. The mind boggles.

Cthulhu_2• 4 years ago

Backwards compatibility and a slow moving industry; adding more to a standardization process will only postpone the release.

More and more programming languages are moving to a more lightweight or scheduled release schema though, e.g. Java that had been stuck in limbo for nearly a decade due to design-by-committee and backwards compatibility concerns by major players.

bluGill4• 4 years ago

Trying to get everything is why C++11 wasn't c++07. The committee spend several years trying to polish things instead of doing a new release. (the committee thought they weren't allowed to release anything before 06/07, otherwise some of what was in C++11 could have been in C++01 - or maybe c++03 but with more in it). Eventually you need to say stop right here, what is done is what we will release, what isn't done will have to wait.

gpderetta23• 4 years ago

It took 10 years to get c++11 out as it was...

oreliazz• 4 years ago

To get something into C++ someone has to actually write a paper and propose it to the standards committee who has to vote and agree on it.

You can't just have some dude write a span.hpp and go "yep, that's going into my compiler v2" - not how standards work.

nynx2• 4 years ago

I would’ve much rather have gotten span into C++11 than variadic templates, for instance. Definitely seems to me like a paper about span would’ve been a lot shorter and easier to write than one about variadic templates.

donatj2• 4 years ago

Silly question from someone who hasn’t written C++ in 20 years and only very vaguely remembers it - if a code path is unreachable, why have the path at all?

Is a default on a switch required? Is lack thereof a compiler warning or something? It’s been a very long time; I only ever seem to recall that kind of “all paths must be handled” from functional languages.

f1shy• 4 years ago

I think the examples are not the best...

Koshkin5• 4 years ago

‘default’ is there by default anyway. This new feature allows to explicitly state that there isn’t one.

beached_whale2• 4 years ago

It can also improve codegen and is a building block of building an assume like macro to convey preconditions to the compiler and optimize potentially on that. The other is at the end of a function that can be guaranteed to never reach that point so that the compiler can know. Its a low level tool and shouldn’t be used without caution

gpderetta23• 4 years ago

It can help both optimizations and static analysis. For example in the switch case in principle the compiler can avoid doing bound checks on the switch jump table. For static analysis it can help flags paths that can actually happen as erroneous.

Cthulhu_2• 4 years ago

Not C++ specific, but the example given - a default case that is not expected to ever be hit - is a "cover all bases" thing, to avoid undefined behaviour. Without the default case, what should happen? In the example given, it would just do nothing, but it would do so silently, which could lead to hours of developer time wasted trying to figure out why it doesn't do anything.

But I can imagine other use cases that are like "this is not supposed to happen" that can cause major issues like buffer overflows. Better to be more defensive and write code that basically says you are aware of code that shouldn't be reachable.

donatj2• 4 years ago

I get that covering all bases is good, but am I reading right that this just tells the compiler not to generate that path? Seems like the opposite.

Wouldn't it be safer just to trigger a panic or something?

bluGill4• 4 years ago

There are a number of reasons.

Having an unreachable block communicates to other humans that you didn't forget the else case, it shouldn't exist. Code is about communicating to the next maintainer of the code.

Unreachable communicates to static analyzers, which can throw an error if it detects a code path that would reach this code, even though otherwise that code path is fine. Also static analysis will stop analysis at this point, and since static analysis often is running into the halting problem having a forced halt means some other heuristic elsewhere will get more time to run and so it can find bugs in a different code path that it wouldn't have analyzed before.

Is a default on a switch required?

Many style guide do not allow a default case on a switch. If you don't have a default case and you add a new item static analysis will flag an error (compiler warning), thus ensuring you look at that section of code that you may not have known about. So unreachable is a way to mark a lot of not possible cases as ones you have thought about, without either skipping them or adding a default.

I only ever seem to recall that kind of “all paths must be handled” from functional languages.

C++ doesn't require all paths be handled, but realistically as a programmer you want to handle all paths. Marking a path as not reachable is a useful way to handle impossible code paths.

klyrs• 4 years ago

It comes up from time to time, for example sometimes you'll have a big enum where most of the values can be handled in a straightforward way, and things are weird and complex for the other values. So you write something like

    int process(my_enum x, state_t state) {
        if (x == my_enum::COMPLICATED) return do_stuff(state);
        switch (x) {
           case my_enum::SIMPLE0: return 0;
           case my_enum::SIMPLE1: return 1;
           case my_enum::SIMPLE2: return 2;
        }
    }

and your compiler complains that my_enum::COMPLICATED isn't handled, even though it clearly was. You generally like these warnings, because they do keep you safe, but in this case, you're smarter than the compiler, but it forces you to put something there. With std::unreachable, it will squelch the warning and not emit extra code. For example, you might be tempted to throw an error -- but if nothing else in the function throws, you end up emitting a bunch of unreachable error-handling code that the compiler can't remove.

agluszak• 4 years ago

A typical use case for this function are switch statements on a variable that can take only a limited set of values from its domain. For instance, an integer that can only be between 0 – 9. Here is a simple example with a switch that checks a char value and executes operations. Only a limited number of commands are supported but the argument is checked before invoking the function so it shouldn’t be possible to receive other values than already handled in the switch.

This is a bad practice. Parse, don't validate - https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

fooker• 4 years ago

Okay, what about when you are writing the parser?

simias• 4 years ago

Byte swapping is important when transferring data between system that use different order for the sequence of bytes stores in memory.

That seems like a glaring footgun to me, to the point where I think I must be missing something.

What I want when dealing with endianess are "from_little_endian/to_little_endian", "from_big_endian/to_big_endian" function pairs that expand to either nop or a byte swap depending on the host architecture.

Exposing the byte swapping directly without this layer on top is asking for trouble because every user will have to make sure that they correctly detect the local endianess before attempting a swap. That's the potentially tricky part, not swapping the bytes.

gpderetta23• 4 years ago

The std::endian enum makes it very easy to find the native endianness.

a13692099934• 4 years ago

That's irrelevant, because there's nothing useful you can do with the native endianness (other than implement (load/store)_(big/little)_N for various combinations of options).

SeanLuke• 4 years ago

I think -- I hope? -- we're seeing the death spiral of this language.

C++'s Biggest Problem: unbelievable, extraordinary, just mind-blowing levels of complexity.

Solution: add more stuff!

ratorx• 4 years ago

I don’t necessarily disagree with the underlying point, but this it’s a weird change to comment on.

The complexity explosion in C++ is due to extra language features etc. not 3 extra, probably well documented, quality of life functions in the standard library.

std::unreachable is the most atypical “function” in this post, but from a code readability perspective, it is pretty clear what it does and it doesn’t really add any new concepts to the language (UB has always been a footgun).

Also, if you want to preserve backward compatibility, all you CAN do is add more abstractions and hope they are simpler to understand and cover the majority of the use cases that the old ones did.

pjmlp3• 4 years ago

While C++ is indeed a complex beast, mastering the whole of Java, C#, F#, Scala, Python, OCaml, Haskell in their latest versions, standard libraries and changes between major releases isn't any easier.

SubjectToChange2• 4 years ago

I think -- I hope? -- we're seeing the death spiral of this language.

In a lot of metrics C++ has never been more popular. And given the direction of heterogeneous programming, C++ is here to stay.

Solution: add more stuff!

In a lot of ways, yes, that is the solution.

Aardwolf• 4 years ago

Why is std::unreachable a function, and why does it require including a header?

It sounds like the functionality of unreachable is to inform the compiler of something, which is what a core language keyword, like "if" or "for", does. Of course then there could be name collisions with the new keyword, so being in std:: might be a solution for that. But that is inconsistent, sometimes they solve this with prepending/appending __ or _t instead, or using obscure enough names like "constexpr" or "nullptr" that probably don't clash

gpderetta23• 4 years ago

Why shouldn't it be a function? The global namespace is a scarce resource.

constexpr can't be a function because it is not used a such. Nullptr could have been std::nullptr, but it is used often enough that it made sense to put it in the global namespace (but note that it had to be nullptr instead of null to avoid collisions, so only two chars saved). The type is still std::nullptr_t.

The C++ standard doesn't really use __ as a prefix, it is a namespace reserved for the implementor. The _t suffix in the global namespace is from POSIX originally then adopted by C; C++ still puts _t names under std.

std::unreachable is a very obscure functionality, polluting the global namespace for it wouldn't have been a good idea.

ryandrake• 4 years ago

Kind of off topic, but is there a good "catch up" guide for people who stopped paying attention after C++11? Like a quick summary of just the useful, practical things you'd actually want to use in production, rather than the parts that are only interesting to computer science academics? Most of the "what's new in C++X" guides seem to just dump everything on you at once. I feel like I should get back into C++ but I don't think I really need to care about folding expressions or std::bit_cast.

eco2• 4 years ago

I found Stroustrop's book A Tour of C++ very useful for catching up with C++14/17. It's relatively short and it's easy to skim through parts you already know well.

It was just updated for C++20 (with some coverage of C++23).

There's always a bunch of CppCon talks for this too. Just pop on over to their YouTube channel.

jahnu2• 4 years ago

Herb Sutter’s Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14

maxnoe• 4 years ago

Effective modern C++ is by Scott Meyers, not Herb Sutter.

WalterBright• 4 years ago

In D an unreachable branch can be indicated with:

    assert(0);

which is used frequently in D. This is a bonus from assert() being a builtin to D rather than a macro.

a13692099934• 4 years ago

The problem with the C++23 std::unreachable is that it invokes undefined behaviour. Calling abort (or panic, or whatever D's assert boils down to when the condition fails), would be a prefectly reasonable way to define unreachable. (That is, for example, basically how I define it in my own code:)

  #define unreachable die("unreachable code reached")

MaxBarraclough• 4 years ago

As the article states, they're doing different things. It's not a runtime check. The point of making it undefined behaviour is that it enables the programmer to provide information to the compiler to enable better optimisation. The compiler is permitted to assume the programmer is correct about the path being unreachable, and may infer accordingly.

kazinator2• 4 years ago

No thanks, I'm going to keep calling abort (ANSI C, 1989) to indicate "control stops here":

Code after an abort() call is unreachable. (Or after any function attributed noreturn).

GCC and Clang know this, and do things accordingly.

For instance, I've seen GCC emit code which assumes that ptr is not null after ASSERT(ptr != NULL), because the custom ASSERT macro called an __attribute__((noreturn)) function in the null case.

abort() has defined behavior; it terminates the program abnormally, as if by raising the SIGABRT signal.

Your own function attributed __noreturn__ can have whatever behavior you want it to have. The one in the ASSERT macro I alluded to above calculates and prints a backtrace and other useful information.

Three new utility functions in C++23

Related Stories