Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three new utility functions in C++23

mariusbancila.ro

Post reply on HN
Print view View original

71–80 of 196 posts

Re: Three new utility functions in C++23

#71

Post by dahfizz »

actionfromafar wrote: post #23
fluoridation wrote: post #21

Earlier quoted context omitted.

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.

Yes, but what was unreachable may get reachable as I do changes to the program. I see the utility when doing highly optimized library code. But for my purposes I much prefer to stick something which flags me (exception or logging or whatever) of "this should never happen" instead of crashing. (Undefined.)

In a real codebase, this would be wrapped by a macro to abort in a debug build but gain the optimizations in a release build.

Re: Three new utility functions in C++23

#72

Post by agluszak »

> 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...

Re: Three new utility functions in C++23

#73

Post by gpderetta »

planede wrote: post #45
a2800276 wrote: post #36

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 sa…

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 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 cor…

Re 3), all the 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.

Re: Three new utility functions in C++23

#74

Post by [deleted] »

dahfizz wrote: post #70
gpderetta wrote: post #61

Earlier quoted context omitted.

For that abort() is just fine. Being UB, unreachable is more about optimizations .

>> and it won't be enabled in all build types. The typical usecase would to wrap this in a #define, so that it aborts on a debug build but you get faster code in a production build.

[deleted]

Re: Three new utility functions in C++23

#75

Post by lvass »

colanderman wrote: post #48
a2800276 wrote: post #36

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 sa…

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 doesn't make sense to me (that reads like a no-op). static_cast introduces a new reserved word which is a big no-no. 3. This is not the same as htonl…

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

Re: Three new utility functions in C++23

#76

Post by usefulcat »

CJefferson wrote: post #11

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).

> 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.

Re: Three new utility functions in C++23

#77

Post by gpderetta »

nynx wrote: post #41

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 ` is a huge one. The mind boggles.

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

Re: Three new utility functions in C++23

#78

Post by XCSme »

pm215 wrote: post #34
XCSme wrote: post #12

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

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…

That makes sense.

Re: Three new utility functions in C++23

#79

Post by XCSme »

Koshkin wrote: post #46
XCSme wrote: post #12

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

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

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

Re: Three new utility functions in C++23

#80

Post by elteto »

halayli wrote: post #7
hoseja wrote: post #3

>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.

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.

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