Endianness is only an issue when reading and writing multi-byte values to files.
For example, in the GIF 89A standard, it states that "Multi-byte numeric fields are ordered Least Significant Byte first." (Which is Little Endian.)
Hence, to read a GIF file, you must read multi-byte values starting with the LSB first and composing your value until you've read the MSB. (In reality, GIF files stick to 2-byte entities maximum, so it is as simple as reading:
1 2 3
|
unsigned value;
value = gif.get();
value |= gif.get() << 8;
|
)
The conversion between endians is done simply so that the value in the file matches the way the running architecture represents multi-byte values.
So, if I were writing a GIF reader that would only work on Windows with Intel 80x86 hardware, I could easily have just written:
1 2
|
unsigned short value = 0;
gif.read( static_cast <char*> (&value), 2 );
|
because both the operating environment and the file are in Little Endian order.
The problem with that is that when the code gets ported over to a MIPS processor (like a Sun SPARC), it will suddenly fail because the operating environment is a Big Endian architecture. Hence, using routines to properly read and compose multi-byte values (like the first example I gave) are better.
This is common enough across network protocols that routines like
ntohs() (network to host short -- where 'short' is a 16-bit entity) and
htons() (host to network short) were created. Frankly, they are available on every extant platform... so you could use them -- assuming you don't mind linking with all the additional networking code. (On Big Endian architectures, the routines do nothing. On Little Endian architectures, the routines simply reverse the order of the bytes. On systems with Mixed Endian byte orders, they do the right thing also...)
Recently, I posted a couple of functions for doing this:
http://www.cplusplus.com/forum/beginner/11431/page1.html#msg53963 . This is my preferred method, because it incurs such a little penalty to simple create a few functions to properly read and write multi-byte values properly and doesn't require all applications to have internet-working capabilities.)
Once the value has been read from file, you no longer need to worry about endianness. Simply use it as you would normally.
1 2 3 4 5
|
unsigned short value;
little_endian_io::read_value( gif, value );
cout << value << endl; // it displays the correct value. Amazing!
value++; // Behold: increment by one!
cout << value << endl;
|
Hope this helps.