Closed changrui0608 closed 2 years ago
Yes, this is a good point. Unfortunately the API so far is structured in an opinionated way, making it difficult to implement this flexibly. The easiest way may just be introducing a second trait "BigEndianFixedInt" (or a more elegant name), which also permits sharing the macro code. Unless you have a better idea?
I will take a look at this in the next few days (hopefully), so stay tuned.
For my needs, I recently found they're kind of unique, I think I eventually have to re-invent something else to meet my needs, then I'm gonna to close this issue, since I may not depends on this on my current work.
Supporting multiple endians may helps people in the future, you may look at this with your plan.
On the implementation way, I personally agree with the easiest way of introcuding new traits, both "BigEndianFixedInt" and shorter "BeFixedInt" sounds good to me, "LittleEndianFixedInt" or "LeFixedInt" could be retained for future, the original "FixedInt" is in machine's endian, everything is explicit, which is good.
Still, thanks for responses.
So far I simply decided (see README) that fixed ints here are going to be LE, but I agree that switching byte orders is useful.
A very simple alternative I came up with - even though not as elegant - is an endian reversal function. Given that FixedInt currently guarantees LE everywhere, reversing will guarantee BE. I will implement this as a stop-gap.
reading/write from network-endian buffer or stream, which I think could be very helpful on network protocol things.