PDA

View Full Version : Struct to QByteArray



Momergil
3rd July 2014, 19:02
Hello

Based on this (http://www.qtcentre.org/threads/59672-Problems-converting-raw-data-to-struct-when-using-QDataStream) topic, I would like to know:

Is there another reasonable way of converting a struct to a QByteArray that doesn't use QDataStream?

Thanks,

Momergil

Edit: the only other way I'm aware now is:



MyStruct structTemp;

//Fill structTemp

char buffTemp[sizeof(structTemp)];

memcpy(buffTemp, &structTemp, sizeof(structTemp));

QByteArray baTemp = QByteArray::fromRawData(buffTemp,sizeof(structTemp )));

anda_skoa
3rd July 2014, 21:21
Well, this is not a reasonable way :)

You can basically use any form of serialization that has a bytestream at the end.

E.g. JSON and then converting the string to the byte array, or XML, or any other text based format.

Or defining your own binary format, etc.

Cheers,
_

Momergil
4th July 2014, 16:05
Well, this is not a reasonable way :)

\o/ Why? =D it does look fast, clear and easy for me :)

Now JSON or XML? o.O I mean, how does converting a struct into a string inside a file and then reading that file to QByteArray is anyway reasonable? :D

About the binary solution, I'vr no idea on how to do that xD


Thanks,

Momergil

anda_skoa
4th July 2014, 16:27
\o/ Why? =D it does look fast, clear and easy for me :)

Usually serialization is used to transport data from one application to another, sometimes even across machine boundaries.

Copying the runtime memory representation instead means that it can only be read by a prgram written in exactly the same language, using the same compiler and the build using the same options, running on the same machine.

And putting external data unchecked into memory has the security implications.



Now JSON or XML? o.O I mean, how does converting a struct into a string inside a file and then reading that file to QByteArray is anyway reasonable? :D

You don't have to write to a file, both QJsonDocument and QXmlStreamWriter/-Reader can work with in-memory destination/sources, including QByteArray.



About the binary solution, I'vr no idea on how to do that xD


QDataStream for example if the communication is between two Qt programs.
Or Google protocol buffers or a hand-crafted format.

Cheers,
_

Momergil
4th July 2014, 18:55
Thanks once again anda_skoa for you reply!



Copying the runtime memory representation instead means that it can only be read by a prgram written in exactly the same language, using the same compiler and the build using the same options, running on the same machine.

Well I certainly don't understand how does that apply to the code I wrote above! o.O (I mean, if you are talking about the code and not about the whole concept of struct-to-array). I just can't see why it would have much of these limitations you mentioned with the exception of the language one, since I agree that the whole thing presupposes that the reading guy will have the header containing that struct specification (which means a C or C++ app). But what does compiler has to do with it? And even more be in the same machine? o.O

ChrisW67
4th July 2014, 22:15
For example, the compiler is free to insert padding bytes to ensure data items within the structure align on convenient boundaries for the machine architecture you are targeting. Different compilers may do this in different ways (or not at all) even on the same machine. A compiler may chose different sizes for the basic types: the standard only requires, for example, that an int is at least as big as a short which is in turn at least as big as a char. One compiler's internal representation for a given class/struct is therefore not reliably the same as another.

Taking the structure between architectures also exposes you to byte order issues even if the compilers agree on exactly how big data elements are and padding is done. A little-endian 4 byte int is not sensible if interpreted as a 4-byte big-endian int.

These issues are precisely why we have mechanisms like QDataStream, or lower functions like htons() or ntohs(), to provide a transportation format that is independent of the internal storage form.