Hi,
I searched a bit on Google and what I see is always "little endian" : Android, IOS, PS4, XBOX ONE...
Is it safe to say all is little endian nowadays ?
If not, here a way used to check the endian :
All the devices you will encounter are little endian.
A small percentage of servers, like AIX, are big endian. You will not encounter these in games, not even for server back-ends. Those are the "big iron" machines running Cobol in the back offices of old banks, or the ancient air traffic controller centers.
An small percentage of microcontrollers are big endian or mixed endian. You probably aren't writing games for an audio signal processor chip.
Every PC, laptop, desktop, server, phone, tablet, game console, or other interesting device for games is little endian.
Even back in the older days, the only time you needed to worry about it was when you were transferring data from one system to another system, such as moving data to/from a "big iron" machine and a terminal. Some data protocol specify "network byte ordering", which is big endian. Some data files also specify big endian, but that is rare these days.
At present and going forward it certainly seems the trend is little endian. But I feel compelled to point out that just one generation ago the consoles were both big endian architectures (X360 and PS3). I would be mildly surprised if it swung that way again, but those PowerPC platforms are still "in the wild", if only currently (semi-recently) supplanted.
Regardless, detecting/supporting either endianness is not terribly difficult so long as you can isolate it to whenever you're serializing bytes, be it networking or file I/O.
Nope. Never safe to say anything like that. It's like structural engineers saying "we don't need to take earthquakes into account because we haven't had earthquake in the last 50 years anyway."
Except earthquakes directly interfere with a bridge, while on the other hand, you have full control what external access exists, and which conditions it should obey to make it work.
You can also test/validate the system endianness at runtime like so (although "runtime" is sort of a misnomer in this case, as the compiler might very well optimize this down to simply the proper result):
You can also test/validate the system endianness at runtime like so...
I'm not aware of any system configuration where the endianess is likely to switch *while your program is running*. Compile-time checks are perfectly adequate.
As to the question of frequency, most ARM chips can run in either endian. Power chips (the newer variants of PowerPC) are also bi-endian. You'll probably never run into such a chip in games development, but if you are writing generalised software, there's still a decent chance.
Just put an ifdef or static assertion in any bit of the code affected by endianness (which should be like, 0% of your structures) and then fix it when you port to one of those platforms later.
I'm not aware of any system configuration where the endianess is likely to switch *while your program is running*. Compile-time checks are perfectly adequate.
Just put an ifdef or static assertion in any bit of the code affected by endianness (which should be like, 0% of your structures) and then fix it when you port to one of those platforms later.
Yes, I was not quite clear enough on the intent. I didn't mean to imply you would need to do this "live" all the time. Rather, you can use it to validate that your assumption about the endianness of the system is valid. To Hodgman's point, an assertion or static assertion at the right place to indicate if there's a mismatch.
