[SDL] little endian and big endian
pphaneuf at gmail.com
Tue Apr 7 07:17:02 PDT 2009
On Tue, Apr 7, 2009 at 9:28 AM, Francisco Bodego Franco
<fran at ikasplay.com> wrote:
> I have one doubt about little endian and big endian issue.
> I want to develop one game for windows, linux and MacOS, can I use the int,
> bool, char and String literals normally? Or I have to create new classes
> that simulate this literals?
You mainly have to be careful while doing I/O or manipulating integers
in strange ways (for example, trying to access the two bytes in an
integer separately, you might find they are inverted). If you're just
doing things normally, as others pointed out, you'll be fine.
One thing that I got caught by is that you don't always think of all
the I/O. While reading/writing files and network communications are
obvious, I once found out the hard way that the sound card on a
Powerbook actually takes little endian samples, even though the
PowerPC CPU in that laptop is big endian!
For reading and writing to files, you can borrow the trick often used
by network communication, which is to standardize on one endianness,
and have some functions used while doing the I/O (checking "at the
borders" of your program, so to speak), using the hton/ntoh family of
macros, for example ("hton" means "host to network", meaning that it
converts from whatever your host system uses to the "network byte
order", so if you get a 32 bit integer from the network, you don't
need to think much about it, just run it through ntohl, and you'll now
have whatever you need for your system).
Strings don't tend to be a problem, since (most commonly) they are
just a sequence of discrete single-byte data, so there's no byte
ordering issue. If you use UTF-16 for your string encoding, that might
not be the case, tough.
The hton/ntoh macros are an example of the "wrappers" mentioned by others.
The mention of sizeof is related to the fact that on some platforms,
an "int" might not be the same size as on another ("long" is a common
offender, where it can be 32 or 64 bits long, depending on the
platform). Again, for I/O, in those cases, you'd want to use something
like the fixed-size integer types from stdint.h, so that when you use
an int32_t, you know that it'll be exactly 4 bytes long, no matter
what platform you're on, for example.
That said, if you use libraries for doing your I/O, like SDL_image to
load images, say, the library should handle those byte ordering
details for you, most of the time. I experienced the problem on my
Powerbook mainly because I was coding my own sound mixer, which had to
manipulate each samples, but if you use a library like SDL_mixer, it
will deal with it for you. The main problems remaining are usually
file formats (but if you use XML, it's all strings, and your XML
library should work around any problem for you) and network
communication (just use the hton/ntoh functions all the time).
I did see some people using C++ who created special types for "network
integers", and had overloaded a number of operators so that they would
automatically convert (using hton/ntoh), but I think that's probably
more trouble than it's worth, the code that interacts over the network
is usually grouped together, making it easy to deal with "by hand".
More information about the SDL