Re: [boost] BOOST_BIG_ENDIAN

From: John Maddock (john_at_[hidden])
Date: 2004-07-25 05:16:59

> 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.

Agreed.

> >
> > 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.

OK could be more theoretical then (except on itanium apparently!)

> 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

That's an even worse maintenance nightmare; at some point there's a
cost-benefit trade-off to be made here.

John.