...
Anyway, before I tried this I was already wondering about the choice of function signatures:
void endian::reorder(T&); // in-place byteswap void endian::reorder(T src, T& dest); // out-of-place byteswap
What is the rationale (or precedent) for these and not
T endian::reorder(T);
?
The endian/conversion.hpp interfaces are very immature compared to the endian/integers.hpp interfaces, so it is well worth taking a hard look at your questions. The unconditional interfaces and conditional interfaces were designed as a set, so they do things in a similar way. If native_to_big, as an example, was supplied only as: T native_to_big(T x); then the code for big-endian systems wouldn't just be a no-op. A copy, no matter how fast, is a slower than a no-op. Of course a really smart compiler might optimize the do-nothing copy away. Also, some real applications deal with records of many fields, so you get long strings of: reorder(rec.f1); reorder(rec.f2); ...etc. It is a bit wordier to have to write: rec.f1 = reorder(rec.f1); rec.f2 = reorder(rec.f2); ...etc. I'll run some timings tomorrow to see how actual release build timings differ. --Beman