5

Short:

  • Does the c++20 endian proposal only deal with integer types, or does it also give information on float types?
  • Will it add useful standard library functions for dealing with endianness?

Dealing with serialization correctly across platforms is difficult, and the weird possibilities of float endianness are even more frustrating (curses to whoever decided ARM middle-endian floats were a good idea). Unfortunately the articles I could find online discussing c++20 features mention integer types but not floats.

Did the standards committee overlook float and double types?
Please tell me no.

Also, the articles I could find seemed to suggest the additions will only provide a way to detect endianness, but not provide standard library functions for converting between different encodings. If that was the case, this doesn't seem any more useful than just standardizing a preprocessor definition.

Can someone knowledgeable about the upcoming c++20 proposals lay out what is (and is not) being included in the new endian features? (... and the 'why' would be awesome if you happen to know)

Barry
  • 286,269
  • 29
  • 621
  • 977
PorkWonton
  • 55
  • 6
  • "*this doesn't seem any more useful than just standardizing a preprocessor definition.*" But it isn't; it's an enumeration. Which means that it is a `constexpr` value, unlike a preprocessor definition which is just a macro. – Nicol Bolas Mar 22 '20 at 04:57
  • instead of looking at articles, here are some links to standards papers themselves [original proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0463r1.html), and [update](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1612r0.pdf). Supporting library call: byteswap ([link](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1272r0.html)) – PorkWonton Mar 22 '20 at 05:07
  • this mentioned byteswap [standards_meeting_summary](https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso_c_committee_trip_report_c20/), but it appears to not have made it in [later_meeting_summary](https://www.reddit.com/r/cpp/comments/cfk9de/201907_cologne_iso_c_committee_trip_report_the/) No mention of byteswap and comment said byteswap didn't make it. Unfortunately it doesn't mention endian either, so are we sure that made it in? – PorkWonton Mar 22 '20 at 05:17
  • [Yes, we're sure](http://eel.is/c++draft/bit.endian). – Barry Mar 22 '20 at 16:07

1 Answers1

2

Does the c++20 endian proposal only deal with integer types, or does it also give information on float types?

As it stands, it'll tell you if all scalar types are big or little endian - or, the horror, they are not and you're dealing with mixed endianess.

All arithmetic types are included in scalars, both integer and floating point types.

The why: Pure speculation, but making a portable test when having seen gazillions of C type punning versions ported to C++ would be one why.

Also, the articles I could find seemed to suggest the additions will only provide a way to detect endianness, but not provide standard library functions for converting between different encodings. If that was the case, this doesn't seem any more useful than just standardizing a preprocessor definition.

You only get a portable way to detect endianess.

Ted Lyngmo
  • 93,841
  • 5
  • 60
  • 108
  • So on an ARM system with little endian integers, I will not be able to tell the endianess of the integers if the floats happen to not be little endian? Or are you saying I can ask for all scalar types if that type is little, big, or neither? – PorkWonton Mar 22 '20 at 04:04
  • 2
    @PorkWonton You will get a mixed result as I made an example of here: https://stackoverflow.com/a/53503457/7582247 – Ted Lyngmo Mar 22 '20 at 04:06
  • Thanks for the clarification. Ugh, this makes the proposal worse than just standardizing something equivalent of gcc's `__BYTE_ORDER__` and `__FLOAT_WORD_ORDER__` preprocessor definitions. – PorkWonton Mar 22 '20 at 04:23
  • @PorkWonton It's one step closer to good :-) It'll also be in C++20 that integers use two's complement. The fact that it's not already standardized has caused _a few_ bugs over the years to say the least. It's perhaps decisions like that that can't be enforced until the last one's complement computer has gone offline. I'm hoping that the endian part we got this time will be accompanied with other goodies in C++13. – Ted Lyngmo Mar 22 '20 at 04:30