4 ms·
An aspect to keep in mind if you do this is (file) portability. Since it's tied to the data structure you could inadvertently tie the data format to a specific
by jwilliams 15y ago
An aspect to keep in mind if you do this is (file) portability. Since it's tied to the data structure you could inadvertently tie the data format to a specific architecture -- e.g. endianness, integer sizes, 32 vs 64 bit, etc.
- mcpherrinm 15y agoThat's certainly a problem that exists, but isn't one that's terribly hard to solve. Network programmers have had this problem from the beginning, with distinct machines communicating. The same techniques can be used when writing to a file instead of a network stream: Explicit integer sizes and endianness fixes this.
- saurik 15y ago... but then you don't have a "zero load time file format", at least on systems that have different endianness than the file was generated. (At least, unless you are willing to have the entire program not assume the endianness of its own internal data structures, which would be kind of insane.)
- palish 15y agoIn the gamedev world, typically little endian is "the fast one", and big endian is where conversion is required. (This is merely because Windows is the dominant gamedev platform.)
- JoachimSchipper 15y agoJust abstract it away: #define NRELATEDWORDS(data, idx) (ntohl(*(uint32_t *) &(data)[idx])
- wladimir 15y agoSome games solve this by rearranging the pointers/values for the target platform on installation (or first load of a data file). On platforms where you don't have installation phase (such as consoles) a fixed endianness can be assumed.