Sizeof wrong with structures ?????

[tonnot]

Thanks.
But the problem of types and endianness are going to be the same if I want to load - save a simple variable , isn't it ?

If you want to load or save a long int to a binary file what would you do ? (Suposing my progr are going to be used on different platforms)

And I dont find references to compile options for Mingw. Can you tell me a usefull help-doc ?

Thanks. Really thank you very much.

[wysota]

But the problem of types and endianness are going to be the same if I want to load - save a simple variable , isn't it ?

It depends on the variable. But in general dumping the variable without any control to disk is not the best thing to do. You should decide whether you store data as big or little endian and perform the conversion before storing and after restoring the data.

If you want to load or save a long int to a binary file what would you do ? (Suposing my progr are going to be used on different platforms)

I would store it in a well defined format -- for example as a 32 bit unsigned big endian natural binary encoded value.

And I dont find references to compile options for Mingw. Can you tell me a usefull help-doc ?

MinGW is GCC. Most of what applies to GCC, applies to MinGW as well.

[squidge]

If I was storing lots of small amounts of data in a file (such as thousands of positions), then I would state the endian format in the file format specification and ensure that format regardless of platform. I would also never use sizeof() as I have been bitten before by that returning different values on different compilers/platforms. I ensure that each object can serialise/deserialise itself from any storage (either disk or memory)

If the data format lent itself to it, or I thought I could be extending the format in the future, then I wouldn't use a binary format at all. The nightmare in supporting lots of different versions isn't worth the compactness of the file and processing speed advantages. So I'd use something like XML (possibly compressed if they turn out large and I knew I had plenty of ram to work with)

[tonnot]

I have found information about the theme.
Intel has little endian always ?
It depends on the operating system ? In that case Windows has one and mac, unix, linux the other?
( I think I know the answer, " it depends ....".)

So, the solution are to set endianness or use types that are going to use always the same endianness.
I can't find usefull information about 'Can I and how set endianness for my prog" (using c++ -Qt + mingw), or 'using safe endianness types '
I have found this link, but I dont understand it .... http://www.realtime.bc.ca/articles/endian-safe

Any help doc about it would be appreciated
Thanks

[squidge]

Its the processor which specifies endianness as its the processor which ends up storing the values (upto 64-bits) in memory.

However, you shouldn't need to worry about this, you should be storing variables in a known endian regardless of processor your application is working on.

Eg. instead of:

int a;
 
write(&a, sizeof(a));

int a;

write(&a, sizeof(a));

To copy to clipboard, switch view to plain text mode 

you would use something like:

typedef unsigned int ui32;
typedef unsigned char uc8;
 
ui32 a;
ui8 c;
 
c = a >> 24; write (&c, 1);
c = a >> 16; write (&c, 1);
c = a >> 8; write (&c, 1);
c = a;
write (&a, 1);

typedef unsigned int ui32;
typedef unsigned char uc8;

ui32 a;
ui8 c;

c = a >> 24; write (&c, 1);
c = a >> 16; write (&c, 1);
c = a >> 8; write (&c, 1);
c = a;
write (&a, 1);

To copy to clipboard, switch view to plain text mode 

then you know you've just written out as MSB (big endian) and guarantee that it will always be MSB regardless. It also guarantees that you'll also always write out 32 bits, regardless if the host OS has a 16-bit int (of course there maybe other consequences of this if you actually use all 32-bits)