Problems converting raw data to struct when using QDataStream

[yeye_olive]

Hmm, I'll have that in mind next time... Manuals I read about using QDataStream to serialize structures to QByteArray and vice-versa didn't mentioned this.

Read the documentation of the QDataStream class itself; it clearly explains that you serialize with << and deserialize with >>. I do not understand how you can expect serialization to be a complex process and deserialization to be trivial at the same time. Suppose you want to serialize a value v of some type (your structure, for example). The value has an internal (architecture and compiler-specific) memory representation A. Serialization using QDataStream gives you another (architecture independent) memory representation B. What you imply is that B is also a valid internal representation for v, which is completely wrong, as you witnessed yourself in your first post.

To be honest, I never actually understood this point. For instance, if I go to stdint.h I'll find

typedef unsigned int		uint32_t;

typedef unsigned int		uint32_t;

To copy to clipboard, switch view to plain text mode 

Which means that there is no difference between I writing my code with unsigned int or uint32_t, since they are the same. If a difference in architecture appears between two different projects, they will do wrong independent on the name I use since they will be synonyms. Of course, for clarity purposes, it's still worth the use of the typedef nomenclature.

Those two types are the same on the specific platform you are compiling for at the moment, but you cannot expect them to be the same everywhere. unsigned int is a typical machine integer, while uint32_t is guaranteed to be 32 bits wide.

[Momergil]

I do not understand...

Well I think I finally got your point My expectation/presupposition was, indeed, doomed to fail some time.

Those two types are the same on the specific platform you are compiling for at the moment, but you cannot expect them to be the same everywhere. unsigned int is a typical machine integer, while uint32_t is guaranteed to be 32 bits wide.

Well, even with you re-stating that + anda_skoa similar comment I still can't see how would that actually work if in all platforms the included header file with such definitions are the same. Of course, if they change from platform to platform (such as e.g. in a given architecture the uint32_t is a typedef for unsigned int and in another is a typedef for unsigned short), than it makes sense, but if they are always a typedef of the same basic 'data type', so changes in the basic 'data type' will affect their typedef equally anyway - which means that a uint32_t in one architecture will be different to a uint32_t in the other anyway.

Thanks,

Momergil

[yeye_olive]

Well, even with you re-stating that + anda_skoa similar comment I still can't see how would that actually work if in all platforms the included header file with such definitions are the same. Of course, if they change from platform to platform (such as e.g. in a given architecture the uint32_t is a typedef for unsigned int and in another is a typedef for unsigned short), than it makes sense, but if they are always a typedef of the same basic 'data type', so changes in the basic 'data type' will affect their typedef equally anyway - which means that a uint32_t in one architecture will be different to a uint32_t in the other anyway.

The typedef varies from platform to platform and guarantees that uint32_t is 32 bits wide everywhere.