Three new utility functions in C++23
mariusbancila.ro
Three new utility functions in C++23
1–10 of 196 posts
Re: Three new utility functions in C++23
#2They 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` somewhere.
For types that aren't enums it should do nothing (maybe `std::identity`)
Re: Three new utility functions in C++23
#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.
Re: Three new utility functions in C++23
#4They 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 ` somewhere. For types that aren't enums it should do nothing (maybe `std::identity`)
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::type.
Re: Three new utility functions in C++23
#5I 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 ) which replace self-written or 3rd party code.
Re: Three new utility functions in C++23
#6Hmm. 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...)
Re: Three new utility functions in C++23
#7>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.
Re: Three new utility functions in C++23
#8>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.
I think they mean for any new protocol, defining it as little-endian.
Re: Three new utility functions in C++23
#9I 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 ) which replace self-written or 3rd party code.
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.
Re: Three new utility functions in C++23
#10>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.
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.