Robert Stewart wrote:
Dave Handley wrote:
Gottlob Frege wrote:
I think what I am saying is that, conceptually at least, the
endian-types come first, and the straight functions are built on top
of that (instead of the other way around as most are suggested).
Now, I wouldn't want that to impact performance, which is why I say
'conceptually'. We can specialize the heck out of
everything so that
performance wins, but I think the conceptual foundation is
important.
I disagree. If you have an endian type then I think you are
coding in from the beginning a need for a copy in order to
endian swap - even if the endian swap is a no-operation.
This discussion isn't necessarily intended to account for swap in place,
which all have agreed is necessary. Rather, I at least am
thinking of this discussion as applying to the object-based approach
and to the copy-based conversion functions.
The problem is with the initial statement above which says "the endian-types come first, and the straight functions are built on top of that". This is what I fundamentally disagree with. IMHO, you have to write the straight functions (in Tom's terminology, swap and swap_in_place), then implement the endian-types on top of that interface. If you do it the other way around you enforce a copy on the function based interface. At least as far as I can see. I don't disagree that many people want and might well heavily use an object-based interface. Robert Stewart wrote:
Next, on naming, I think we should be very careful that we
don't over-think the naming question. I'll ask a general
question. What term does everyone use when talking about
endian swapping? Certainly in my programming career I've
never heard it called anything other than endian swapping.
Also (and I know this shouldn't be taken as a definitive
source) Wikipedia refers to the process of changing
endianness as a byte swap. Shouldn't we use swap because
that is what everyone knows the process of changing
endianness as? That's my 2d, but I'm not wholly against
another naming option.
While I sympathize with your position, it has been noted that "swap"
is a very bad choice because of std::swap(), boost::swap(), etc.
Those functions have a distinct behavior and purpose that endianness
conversion does not satisfy. Considering that our work could be
standardized in the future, can you imagine the committee
accepting "swap" as the name? I can't. That implies the need to
find another name.
I agree that the existence of std::swap() is an issue. In that context I would argue for something more like boost::endian_swap. I think changing the verb used is an obfuscation and not necessarily helpful. Dave