D - happy-endiness
- "Serge K" <skarebo programmer.net> Aug 28 2001
- Chris Friesen <cfriesen nortelnetworks.com> Aug 29 2001
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
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








Chris Friesen <cfriesen nortelnetworks.com>