www.digitalmars.com         C & C++   DMDScript  

D - happy-endiness

reply "Serge K" <skarebo programmer.net> writes:
Just a little idea about more portable code with less conditional compilation...

In >90% cases little-endian / big-endian conversions are used to access
external data with predefined format.
In such cases it's more clear and portable to specify byte order explicitly as
a type attribute.
By default everything has byte order native for the target platform.
This attribute can be changed locally if necessary:

// something like this:

big_endian  uint32  *p; // pointer to big-endian data

little_endian
struct  SomeData
{
    int32  a_little-endian;
    big_endian  int16  b_big-endian;
    uint16  c_little-endian;
...
}
Aug 28 2001
parent Chris Friesen <cfriesen nortelnetworks.com> writes:
Serge K wrote:

 In >90% cases little-endian / big-endian conversions are used to access
external data with predefined format.
 In such cases it's more clear and portable to specify byte order explicitly as
a type attribute.
 By default everything has byte order native for the target platform.
 This attribute can be changed locally if necessary:
 
 // something like this:
 
 big_endian  uint32  *p; // pointer to big-endian data
 
 little_endian
 struct  SomeData
 {
     int32  a_little-endian;
     big_endian  int16  b_big-endian;
     uint16  c_little-endian;
 ...
 }

The problem I see with this is that if you do any kind of manipulation of b_big-endian on a little-endian machine you'll end up doing a lot of endian conversion unnecessarily. By specifying it explicitly you can leave all the endian conversion until it really has to be done. -- Chris Friesen | MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada | email: cfriesen nortelnetworks.com
Aug 29 2001