For generic endian conversions, keep in mind the restrictions for floating point types (and other types with similar properties). It might be worthwhile putting in an "is_integral" check in the generic function implementations. I see a number of projects where I work that blithely endian swap and pass around binary floating point values in distributed applications, not understanding the brittleness of this design. For example, in the following:
template <class T, class U> T big_endian_cast(U);
(and similar little_endian_cast function)
If T and U are floating point types, then: double val1 = someVal; // little endian, for example // ... double val2 = little_endian_cast<double>(big_endian_cast<double>(val1)); For many values, val1 != val2; (For all integral types in the above casting functions, all possible values will have val1 == val2.) This is due to floating point normalization and other non-obvious operations that might be silently applied to the internal bits when values are moved to / from registers. And, even though IEEE 754 is pretty much the standard floating point implementation on modern platforms, that shouldn't be assumed. I can't remember if Beman's endian facilities addressed floating point swapping, but any accepted Boost endian facility needs to address non-integral types in some form or fashion (either by restricting, or properly implementing). I faintly remember some discussions on this subject in the Serialization portable binary archive, or maybe in the Math floating point utilities, but a quick glance at 1.43 documentation doesn't provide specific code for endianness handling in either library (I may have missed it). Cliff