Tomas intends to supply his own version in his library.
Correct.
There is no Boost.Endian library as yet.
That is true. However, there is one in the review queue which is the main reason for my trying to write one, as I explained in my original RFC post, as I am sure you recall.
I'm quite certain, however, that Tomas would model his version on Beman's and give credit or would work with Beman to create a modified, joint submission.
Of course.
I dislike referring to the function-based interface as "untyped" and the higher level interface as "typed." Perhaps we could use "function-based" and "object-based" as the adjectives?
Thank you.
It very likely should be reimplemented on the function-based interface so that there is just one implementation of a given swap routine.
Absolutely. The main reason for this, as I've already mentioned, that I intend to implement the swapping using machine instructions, where available.
Several of us have agreed that including support for arithmetic operators is misleading.
Agreed completely.
Whether Tomas or others have still different ideas on the interface remains to be seen,
Not really. The endian objects should be pretty trivial to write once the function-based machinery is done.
I can imagine any packed byte protocol requiring this.
Ahh... When I saw Vincent's post, he wrote "another feature the endian class provides and is the ability to work with integers with an arbitrary number of bytes" endian<big, int, 24> i; endian<big, int, 16> j; endian<big, int, 24> j; Hence I was reading the above as three integers 24, 16, 24 bytes long, which is why my eyebrows were raised. But I think the correct reading would be "an integer type with 24, 16 and 24 *bits*" respectively, no? If that's the case, I don't really see a problem. If we are, however, talking about arbitrary precision integers, I might be more twitchy. Tom