Problems converting raw data to struct when using QDataStream

[Momergil]

If you use QDataStream to serialize, you must use QDataStream to deserialize.

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.

By the way, your code should not depend on the precise layout of the serialized data. Just let QDataStream encode and decode, or design your own format as I explained before. Also, do not use types such as "unsigned int" in your structure because the range of values of this type depends on the architecture. Use a fixed-size type such as uint32_t.

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.

Thanks,

Momergil

[anda_skoa]

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.

Well, you need a compatible deserialization. Whether that is QDataStream or a compatible bytestream parser doesn't matter.
Like when you serialize to XML using QXmlStreamWriter, you can use any XML parser to deserialization, not necessary QXmlStreamReader

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.

The point of these types is that they are guaranteed to be of the given size.

Cheers,
_

[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.