More data help

goetz

Ah, sorry, I misread the docs. You'll have to convert the data to an int yourself:

@
qint16 bar = ba.at(0x64) + (ba.at(0x64 +1) << 8);
@

QDataStream is not an option?

jnewing

I was unable to get datastream to work :/ ether, have you tried it?

andre

QDataStream works reliably for me. If you have the option of using it, I suggest you do.

Just make sure that if you stream integers in and out, you use one of Qts explicit types: quint16, qint64, etc., so you have well defined items in your binairy file. These types are guaranteed to be the same on all supported platforms. Also, it is wise to explicitly set a version for the datastream at both ends.

You can even overload the operator<<() and operator>>() for your class or struct, and stream the whole block of data in one go that way.

goetz

[quote author="jnewing" date="1303253359"]I was unable to get datastream to work :/ ether, have you tried it?[/quote]

It works perfectly. But you must create the file using QDataStream for writing too!

jnewing

I found a quick simple way, here is an example:

@
QDataArray foo; // is filled with binary data
qint16 bar = static_cast<qint16>(data[0x5e]);
@

that works quite efficiently.

thanks: Volker, Andre

goetz

This code is not platform independent (big/small endian!). You will run into some troubles eventually. Do yourself a favor and do it the right way from the very beginning!

jnewing

[quote author="Volker" date="1303300686"]This code is not platform independent (big/small endian!). You will run into some troubles eventually. Do yourself a favor and do it the right way from the very beginning![/quote]

Yah your right, thx again.

tobias.hunger

"QtEndian":http://doc.qt.nokia.com/4.7/qtendian.html has some helper functions for endianess issues. A little known corner of Qt:-)

jnewing

[quote author="Tobias Hunger" date="1303308248"]"QtEndian":http://doc.qt.nokia.com/4.7/qtendian.html has some helper functions for endianess issues. A little known corner of Qt:-)[/quote]

So using this tasty little tidbit and because I already had my data into a QByteArray I wrote some functions in a untility class as follows;

@
qint16 ByteUtils::extractUInt16(const QByteArray& data, int offset, bool bigendian)
{
if (bigendian)
return qFromBigEndian<qint16>((uchar*)data.mid(offset, 0x2).data());
else
return qFromLittleEndian<qint16>((uchar*)data.mid(offset, 0x2).data());

}

qint32 ByteUtils::extractUInt32(const QByteArray& data, int offset, bool bigendian)
{
if (bigendian)
return qFromBigEndian<qint32>((uchar*)data.mid(offset, 0x4).data());
else
return qFromLittleEndian<qint32>((uchar*)data.mid(offset, 0x4).data());

}
@

works like a charm ;) thanks all

tobias.hunger

I'd just decide on one byte order to use in the file and stick with that. That avoids the bigendian bool and the if/else. Branches are always slow and avoiding them in a method that is called all the time is a good idea: Extracting ints from a data file smells like something that will happen rather often.

Why do you need the data.mid()? That constructs a temporary object that is not necessary. @data.constData() + offset@ should work just as well as @data.mid(offset, 2).data()@ without creating a temporary object.

I'd also try to use constData whenever possible. Using data() the way you do the compiler might think it needs to copy the temporary object you created since somebody might want to write into those bytes. Using constData is a very clear hint that this is not going to happen and the compiler can optimize the copy out. Of course it might be intelligent enough to do it for the data() case, too, but who wants to bet on the compiler being intelligent? ;-)

jnewing

[quote author="Tobias Hunger" date="1303314614"]I'd just decide on one byte order to use in the file and stick with that. That avoids the bigendian bool and the if/else. Branches are always slow and avoiding them in a method that is called all the time is a good idea: Extracting ints from a data file smells like something that will happen rather often.

Why do you need the data.mid()? That constructs a temporary object that is not necessary. @data.constData() + offset@ should work just as well as @data.mid(offset, 2).data()@ without creating a temporary object.

I'd also try to use constData whenever possible. Using data() the way you do the compiler might think it needs to copy the temporary object you created since somebody might want to write into those bytes. Using constData is a very clear hint that this is not going to happen and the compiler can optimize the copy out. Of course it might be intelligent enough to do it for the data() case, too, but who wants to bet on the compiler being intelligent? ;-)
[/quote]

I have no control over the file and it has both bigendian and littleendian values (just to make my life hard) as it was a pc game that was ported to xbox 360 :s

Also you're 100% right I'll use the data.constData() + offset as I have no real need for a temp object :) thanks again.