More data help
-
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.
-
-
"QtEndian":http://doc.qt.nokia.com/4.7/qtendian.html has some helper functions for endianess issues. A little known corner of Qt:-)
-
[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
-
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 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.