Three new utility functions in C++23 • Hacker News Board

Re: Three new utility functions in C++23

#91

Post by gpderetta » Wed, Nov 09, 2022, 2:58 PM UTC

flohofwoe wrote: post #42

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…

> ...`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 look…

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.

Re: Three new utility functions in C++23

#92

Post by Aardwolf » Wed, Nov 09, 2022, 2:58 PM UTC

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

Re: Three new utility functions in C++23

#93

Post by mirsadm » Wed, Nov 09, 2022, 2:59 PM UTC

shin_lao wrote: post #87

elteto wrote: post #80

Earlier quoted context omitted.

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

ARM big endian, so you're wrong, and it takes literally nanoseconds to byte swap.

Not true. Most are setup to run little endian but support both.

Re: Three new utility functions in C++23

#94

Post by kllrnohj » Wed, Nov 09, 2022, 3:05 PM UTC

shin_lao wrote: post #87

elteto wrote: post #80

Earlier quoted context omitted.

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

ARM big endian, so you're wrong, and it takes literally nanoseconds to byte swap.

ARM supports both big & little endian, but basically everyone only uses little endian on ARM.

Re: Three new utility functions in C++23

#95

Post by gpderetta » Wed, Nov 09, 2022, 3:07 PM UTC

Aardwolf wrote: post #92

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/app…

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.

Re: Three new utility functions in C++23

#96

Post by colanderman » Wed, Nov 09, 2022, 3:08 PM UTC

lvass wrote: post #75

colanderman wrote: post #48

Earlier quoted context omitted.

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?

Depends on what's you're targeting, but if you're coding for say, AVRs, you're not using C++, but rather C, in which case `unreachable` is your friend. [1]

[1] https://en.cppreference.com/w/c/program/unreachable

Re: Three new utility functions in C++23

#97

Post by a2800276 » Wed, Nov 09, 2022, 3:08 PM UTC

tlb wrote: post #53

chrisseaton wrote: post #44

Earlier quoted context omitted.

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?

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.

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

But I don't see a reason why this is not be possible with an attribute? (I realize this is a purely aesthetic call from me .. a function that doesn't actually get called seems out of place). My guess would be that using a function allows niche compilers that don't support attributes to support `unreachable` and is easy to implement for compilers already using __builtin

Re: Three new utility functions in C++23

#98

Post by gpderetta » Wed, Nov 09, 2022, 3:09 PM UTC

planede wrote: post #81

gpderetta wrote: post #73

Earlier quoted context omitted.

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

There is one strong difference between byteswap and other operations within . byteswap semantically works on the object representation of the integer, while all other operations semantically work on the integer value, expressed in powers of two. The C++ language has no strong requirements on the object representation of the underlying integer. The C++20 guarantee of two's complement also only just expressed in terms…

Thanks, I didn't catch this difference between byteswap and the other functions.

Re: Three new utility functions in C++23

#99

Post by [deleted] » Wed, Nov 09, 2022, 3:12 PM UTC

a2800276 wrote: post #97

tlb wrote: post #53

Earlier quoted context omitted.

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.

> 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. But I don't see a reason why this is not be possible with an attribute? (I realize this is a purely aesthetic call from me .. a function that doesn't actually get called seems out of place). My guess would be that using a function allows niche compilers that…

[deleted]

Re: Three new utility functions in C++23

#100

Post by gpderetta » Wed, Nov 09, 2022, 3:13 PM UTC

simias wrote: post #83

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

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