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

191–196 of 196 posts

Re: Three new utility functions in C++23

#191

Post by gpderetta »

addaon wrote: post #145
int_19h wrote: post #142

Earlier quoted context omitted.

There's still way, way more little-endian platforms, and it's not likely to change in the future. So it makes sense to use the representation that's most efficient for them when designing protocols.

The efficiency difference is negligible; the cost of an in-register byte swap is basically zero compared to the cost of getting the word from memory into the register to begin with. The bigger deal is making sure that people remember that we /are/ still in a bi-endian world, and writing protocols and code with that in mind.

The performance cost in isolation is not high, but the benefits of being able or reinterpret cast the buffer you got form the network and access it directly without any intermediate preprocessing is high. Most programming languages do not allow accessing fields in an endian agnostic way, you need accessors and a lot of custom code, so the code complexity benefits of ignoring the issue are great.

Re: Three new utility functions in C++23

#192

Post by lelanthran »

s28l wrote: post #47
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. 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…

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

Re: Three new utility functions in C++23

#194

Post by Findecanor »

kllrnohj wrote: post #165
Findecanor wrote: post #151

Earlier quoted context omitted.

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

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 or BigEndian 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)

Of course that has crossed my mind, but I am not sure that there aren't opportunities for optimisation left if the compiler would retain higher-level information.

Re: Three new utility functions in C++23

#195

Post by MaxBarraclough »

a1369209993 wrote: post #184
WalterBright wrote: post #136

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.

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

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.

Re: Three new utility functions in C++23

#196

Post by gpderetta »

kllrnohj wrote: post #165
Findecanor wrote: post #151

Earlier quoted context omitted.

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

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 or BigEndian 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)

https://www.boost.org/doc/libs/1_78_0/libs/endian/doc/html/e...
Post reply on HN