On Sat, 24 Jul 2004 11:57:50 +0100 "John Maddock" <john@johnmaddock.co.uk> wrote:
I think this one has come up before: in general there is no way tell what the endianness is without doing a runtime test, there's also the problem that there are more than two orderings possible, for example for 4 byte types the byte ordering could be any of:
Thanks, John! Interesting. I am unaware of the impossibility of it. The only complaints I know of with detecting architecture through macros is having to modify the code for each architecture (ala detail/limits.hpp). It is not the best in the world, but that is mostly because of the maintenance issues.
1 2 3 4 4 3 2 1 2 1 4 3 3 4 1 2
Of the above, I only know of three that are actually in use, and the third (3412) has not been around since the early PDP machines. Of course, I am not familiar with all architectures.
throw in 8 or 16 byte types, plus floating point types, and things get complicated :-(
Again, I think the possibilities outstrip reality, and reality is the only thing that counts here... as long as each architecture has a specific #define that can be detected at compile time. The worst thing is that a particular architecture may not be supported, and a #error can be issued. I imagine architectures are consistent themselves, but something like this would help if that were necessary: #if defined(__i386__) #define BOOST_BYTEORDER_16 12 #define BOOST_BYTEORDER_32 1234 #define BOOST_BYTEORDER_64 12345678 #elif defined(__sparc__) #define BOOST_BYTEORDER_16 21 #define BOOST_BYTEORDER_32 4321 #define BOOST_BYTEORDER_64 87654321 #elif defined(__dinosaur__) #define BOOST_BYTEORDER_16 21 #define BOOST_BYTEORDER_32 4321 #define BOOST_BYTEORDER_64 87654321 #else #error Byte ordering undetected #endif