Little/Big Endian test code in machine and file

[2kaud]

If you have files that can be used by both big and little endian systems, one way is not to use binary numbers but instead have them in the file as they are displayed as chars. Then programs can extract the numbers as chars and convert to the correct internal representation as needed.

[OReubens]

As 2Kaud says, storing everything as strings (or use something like xml) is an easy method for avoiding the issue entirely.

If you are writing doubles.
then...
1) you may need to deal with endian-ness of the data
2) you may also need to deal with different internal binary representations of the double type
3) note that endian ness is only half the problem. there are also systems where bits in a byte are stored in memory in reverse. so you may not only have to deal with byte ordering, but also bit-ordering.

again, this all depends on what types of systems the C++ needs to compile for (truely portable code takes quite a bit of effort)
and/or what systems your data can come from.

Note that the common approach on the internet is to assume all data is big-endian (this is true for IP packets etc.) so you need to swap in intel machines.
If you have the luxury of deciding the file format... THen the "easy" way is to avoid the issue entirely and use a text format, while typically a bit slower, and harder to achieve in fixed record sizes, there are advantages in the fact the files remain "user-editable" and typically are easier to access from other programs.

[jkepler]

Hi again,

I totally agree with you both. Remaining with text data is safer. I'll implement my files in that way - at least is universal.

The problem might be the size of the files (will a microsoft database be better? I wonder...) ...I'll start thinking about that instead of waisting my time with "endian" issues... :/

Kind regards,

JKepler

[OReubens]

a database typically takes care of endianness at the driver level.
but it may be difficult to transfer a full database between systems regularly (that's not what databases typically do)

[2kaud]

Between which systems are you going to share these files and what is the volume of data shared?

[Igor Vartanov]

a database typically takes care of endianness at the driver level.
but it may be difficult to transfer a full database between systems regularly (that's not what databases typically do)

Well, at least SQLite states:

The database file format is cross-platform - you can freely copy a database between 32-bit and 64-bit systems or between big-endian and little-endian architectures.

[Philip Nicoletti]

CFD codes write out in binary, since writing "text"s would be considerably slower and increase the size of data written. They usually take care of it one of two ways:

1) similar to "netcdf classic" : always write out big endian, and the library takes care of any conversians during the read/write process

2) always write out native, and the library take care of any needed conversions when reading.

CFD codes often have an to read/write a text formatted file also. But I have never seen anyone need to do that.

[jkepler]

Actually, I've heard about SQLite a long time ago. It's interesting that point.

But I've got something else in mind....

Either way, I'll explore it.

Cheers,

JKepler