Re: Bytes' order with different C++ compilers

On May 15, 6:04 pm, Bart van Ingen Schenau <b...@[EMAIL PROTECTED]
>
wrote:
> Alan McKenney wrote:
> > To go on a tangent:
>
> > So far, I have always been able to
> > write code that did not depend upon the platform's
> > byte ordering.  Can anyone think of applications
> > (other than hardware-dependent applications)
> > which cannot be coded to be independent of the
> > host's byte ordering?
>
> Most communication protocols specify a byte order, so the parts of an
> application that have to deal with such protocols are by definition not
> byte-order independent.
>
> As it is not uncommon to work on a little-endian processor, and many
> protocols specify a big-endian ordering, you will often notice it quite
> fast if you made an error in the conversions. :-)

Obviously, if  you are receiving data as a stream of bytes,
you have to know whether binary values larger than 8 bits
are being sent msb first or lsb first (and it may vary
within a message.)

That's why I asked about the _host_'s byte ordering.

If a 32-bit integer is being sent in 4 bytes, msb first,
there are two ways of reconstructing the value:

A.   // only works if host is big-endian

      unsigned char *buf = ....
      unsigned long uint32value;

      memcpy( &uint32value, buf+ipos, 4 );

B.   // works regardles of endianness of your host

      uint32value = ( buf[ipos]   << 24 ) |
                    ( buf[ipos+1] << 16 ) |
                    ( buf[ipos+2] <<  8 ) |
                      buf[ipos+3] ;


I generally use B, to avoid having to worry
about endianness.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm
for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]