QByteArray does not process 0x80

[mohanakrishnan]

hi
im using qbytearray to store hexadecimals and process it.


QByteArray ba;
ba.resize(1);
ba[0] = 0x7e;
if(ba.at(0)==0x7e)
{
//write the data to serial port
}

the above code works
my problem is if i use the hex value as 80 (ie greater t han integer 127)
im unable to process the condition like below


QByteArray ba;
ba.resize(1);
ba[0] = 0x80;
if(ba.at(0)==0x80)
{
//write the data to serial port
}

it does not work ,is there any settings?? to be done??
or it accepts from -127 to 127
can anyone help me???
thanks
:crying::confused:

[squidge]

You are comparing signed and unsigned values. Cast one of them to a signed value, or the other to a unsigned value.

[mohanakrishnan]

hi
thank for ur help pls tell me how to cast qbytearray to unsigned ??
can u tell me??
:eek:

[wysota]

Look what QByteArray::at() returns - a char. If you want to compare it against 0x80 it should probably be unsigned char or an int, so cast it to one of the types as already suggested. Your compiler should have told you that, didn't it?


main.cpp:9: warning: comparison is always false due to limited range of data type

[mohanakrishnan]

hi wysota
it is working but when in need to check each and every byte of the qbytearray then
i need to call the conversion function those many times!!
and my one more question is ,,qbytearray can only store -127 to 127??
and not from 0 to 127!!
pls tell me ...
thanks:):)

[wysota]

it is working but when in need to check each and every byte of the qbytearray then
i need to call the conversion function those many times!!
If you don't call QByteArray::at() then you won't have to perform the conversion.


and my one more question is ,,qbytearray can only store -127 to 127??
and not from 0 to 127!!

It has nothing to do with QByteArray. char is your limitation here.

[squidge]

and my one more question is ,,qbytearray can only store -127 to 127??
and not from 0 to 127!!
pls tell me ...
thanks:):)

qbytearray stores standard signed 8-bit values, so that would be -128 to +127. It's not -127, as there's no -0 value, where as there is a +0, so + can only go upto 127.

[wysota]

Byte array stores bytes. Bytes in modern architectures have 8 bits. 8 bits allow us to store 256 different values. Therefore QByteArray can store values from 0 to 255 or from -255 to 0 or from -128 to 127 or from -64 to 191 or <provide your favourite two numbers that differ by 255>. It's all just a matter of interpreting the values which is exactly what casting to specific types does - it interprets values.

Another fact is that QByteArray is meant to store character strings, that's why char is its natural mapping type. If you want to store eight bit integers, you can use QList<quint8> for that. This way you won't have problems with mapping to the interpretation of numbers most obvious for humans - natural numbers. quint8 is a typedef to unsigned char by the way...

[mohanakrishnan]

hi
thanks for ur suggestion .i used qlist<quint8> which is sucessful .....
thanks..
:D

[Coises]

QByteArray ba;
ba.resize(1);
ba[0] = 0x80;
if(ba.at(0)==0x80)
{
//write the data to serial port
}


Use '\x80' instead of 0x80 in the comparison.

[mohanakrishnan]

hi coises,
it is amazing ,it works well ,im trying to check this for the past one week..
now i adopted using qlist <quint8> and char datatypes.but i ll use this also..
thanks a lot
:)

[yren]

Byte array stores bytes. Bytes in modern architectures have 8 bits. 8 bits allow us to store 256 different values. Therefore QByteArray can store values from 0 to 255 or from -255 to 0 or from -128 to 127 or from -64 to 191 or <provide your favourite two numbers that differ by 255>. It's all just a matter of interpreting the values which is exactly what casting to specific types does - it interprets values.

Another fact is that QByteArray is meant to store character strings, that's why char is its natural mapping type. If you want to store eight bit integers, you can use QList<quint8> for that. This way you won't have problems with mapping to the interpretation of numbers most obvious for humans - natural numbers. quint8 is a typedef to unsigned char by the way...

I think it is a design flaw in the Qt itself. Whenever involves an I/O operation, the byte type should be quint8 or unsigned char, not the char. Because the unsigned char covers the char very well. That is why everybody else defines their I/O buffer as void* or unsigned char*. Only Qt uses char*! (look at the QIODevice, QFile, QByteArray). When you deal with data in COM port, Bluetooth, FTP, or image files, you have to cast the raw bytes to chars first. Even their "RawData()" takes a char* type. Yes, it is doable, but it is confusing. In my limited knowledge about computer, I really do not know why they ever choose to design like that.

[squidge]

To be honest 'char' doesn't specify the type. Most compiler will treat 'char', 'signed char' and 'unsigned char' as three completely different types, and you can normally tell the compiler which of the last two you prefer when you specify the former.

In the automotive industry, if you use the type 'char' you can get cautioned by the code review board because of the above. You have to always prefix it with 'signed' or 'unsigned' to state exactly which you meant (or use an appropriate typedef).

QByteArray uses char because it's really meant for text, and is also used by classes that process text (eg. QString). If you want a string of unsigned char's, then the class is of lesser use to you, so a more practical way would be QList<quint8>.

[wysota]

Because the unsigned char covers the char very well.
Really?

Explain this then:

#include <QtDebug>

int main(){
char c;
unsigned char uc;
c = -14;
uc = -14;
qDebug() << (int)c << (int)uc;
return 0;
}

With the result of:

$ ./c
-14 242
Could you remind me how to store -14 in unsigned char? Maybe I'm just doing it all wrong...


That is why everybody else defines their I/O buffer as void*
In C, not C++. Using void* in C++ is an error as void doesn't implicitly cast to/from any type in C++ as it did in C. And eventually you will have to make a cast to something and if so, why use void* in the first place?


Only Qt uses char*! (look at the QIODevice, QFile, QByteArray).
And this is bad, because...?


When you deal with data in COM port, Bluetooth, FTP, or image files, you have to cast the raw bytes to chars first.
You mean when using void*? And that's a good thing, because.... ?