QDataStream bytes order
I am receiving a stream of bytes from the serial port, as a QByteArray
this QByteArray is passed to a QDataStream and then the order of the bytes is changed to Little Indian
stream.setByteOrder(QDataStream::LittleEndian); stream.setVersion(QDataStream::Qt_4_5); stream >> parameter1; stream >> parameter2; stream >> parameter3;@
if the data contained the following bytes
byte1, byte2, byte3, byte4, byte5
what is the order of the bytes after the little indian
byte5, byte4, byte3, byte2, byte1...?
parameter2(byte4, byte3)? OR (byte3, byte4)?
parameter3(byte2, byte1)? OR (byte1, byte2)?
I am sorry it just that I am a little bit confused??
No. The endianness only applies to the stored data itself, not the order in which you stored them. Qt will not magically reorder your stream reading. So, parameter 1 will be in byte 1, parameter 2 will occupy bytes 2 and 3, and parameter 3 bytes 4 and 5. The endianness only applies to the format of these (sets of) bytes.
but shouldn't it be:
because it is .....Little indian??!!
No, it should not. Little Endian does not mean that the whole data structure is read back-to-front instead of the other way around.
so if I understood you right, then it depends on the received data structure, if it is
already in the Little indian order (least significant byte to Most significant byte) then
leave it as it is , and if not then read back-to-front
.....? is that what you mean
No, no, no.
To cite wikipedia:
[quote]In computing, the term endian or endianness refers to the ordering of individually addressable sub-components within the representation of a larger data item as stored in external memory (or, sometimes, as sent on a serial connection).[/quote]
That is, the endianness only applies to the internal ordering of the sub-components of the data representation. It does not apply to the ordering of these subcomponents within the data representation itself.
The order of your data stream itself is not changed anywhere, or by anyone. It will stay as it is. If your data is written in the order parameter1, parameter2, parameter3, they will stay in that order and should be read back in that order, no matter what endianness was used in writing. The endianness only applies to the byte ordering within these parameters.
Reflect a bit on what would happen if it applied to the whole data representation in the case of working with a large data stream (say, a HD video streaming service). Do you really think that in case a little-endian prepresentation would be used, the whole datastream needs to be transferred to the client before that client can start processing it? You think that the first frame of the video on that stream will be at the end of the stream? That would not make a very good streaming service, would it?