Note that it seems rare indeed to have a utility that does nothing but endianness conversion rather than needing to do something to the data during the conversion.
I think what you describe is pretty close to what I had in mind. And while the utility which does nothing but endian conversion does seem a bit far fetched (perhaps some sort of network bridge which translates between two different network layers?), I think a far more likely scenario is a program that examines and modifies a portion of the data while performing "regularization" on the rest of it. I certainly didn't want to preclude that use case.
Assuming an API like Tomas suggested, the utility can do all conversions with at most one swap. That efficiency is only possible, however, if the utility does nothing to the data during the conversion.
Agreed. Still, there seems no good reason to preclude it. There are many great programs I can't even begin to dream about.
enum host_relative_byte_order { big_endian, little_endian };
I prefer to use types to enums for the tags.
template <host_relative_byte_order, class T> T from(T); <snip code>
I just want to make sure - your only issue right now is with the function names, is that correct? Please don't take this the wrong way, as this is just a matter of taste, but I find your interface worse than mine. It seems that you've gone from the two functions to seven or eight. As for the type conversions, I don't see why you need the endian swapper to do them. Would you be perhaps able to share a use case for this?
template < host_relative_byte_order From , host_relative_byte_order To , class T
T swap(T);
Finally, I have tried and rejected the approach which includes the "from" and "to" endianness. The main reason is that I've found that I, myself, and other developer using the library, had trouble remembering which parameter was "from" and which was the "to", leading to bugs. Hence the "machine_to_big" tag, which is completely unambiguous. Thanks, Tom