Converting uint8_t data to a format that QByteArray can use?
-
I'm working with the pleora sdk and I receive the image data in a proprietary structure (PvBuffer). But, they have a couple of methods to help convert the data which I get back as a unint8_t *.
My ultimate goal is to insert the data into a SQLite database. The example I'm following, puts the data in a QByteArray. then performs the insert.
I'm not sure how to convert the data from uint8_t * to a QByteArray.
PvBuffer dataFromCamera = getMyData(); PvImage img = dataFromCamera.getImage(); uint8_t *rawData = img.GetDataPointer(); //Everything is good to this point. unsigned char *c = static_cast<unsigned char *>(rawData); //This is ok. QByteArray ba(c); //This line gives an error: no matching constructyor for intialization of 'QByteArray' //No known conversion from unsigned char * to const char *.
Is there another way to instantiate a QByteArray with the data?
-
Hi,
You can use a reinterpret_cast. You should also give the size parameter to ensure you have the right amount of data copied.
[edit: fixed cast type SGaist]
-
uint8_t
isunsigned char
, so your cast does nothing at the moment.QByteArray in contrast, uses
char
, which is signed for most compilers. Also, I'm not sure ifstatic_cast
works for pointers, I think you needreinterpret_cast
.The following should work (of course all lines can be written as one, but so it's better understandable):
const uint8_t *rawData = img.GetDataPointer(); const char *c = reinterpret_cast<const char *>(rawData); QByteArray ba(c);
Regards
-
@aha_1980 said in Converting uint8_t data to a format that QByteArray can use?:
uint8_t is unsigned char, so your cast does nothing at the moment
There are machines where a char consists of more than one byte though
-
@Daniel-Williams said in Converting uint8_t data to a format that QByteArray can use?:
I'm working with the pleora sdk and I receive the image data in a proprietary structure (PvBuffer). But, they have a couple of methods to help convert the data which I get back as a unint8_t *.
My ultimate goal is to insert the data into a SQLite database. The example I'm following, puts the data in a QByteArray. then performs the insert.
I'm not sure how to convert the data from uint8_t * to a QByteArray.
PvBuffer dataFromCamera = getMyData(); PvImage img = dataFromCamera.getImage(); uint8_t *rawData = img.GetDataPointer(); //Everything is good to this point. unsigned char *c = static_cast<unsigned char *>(rawData); //This is ok. QByteArray ba(c); //This line gives an error: no matching constructyor for intialization of 'QByteArray' //No known conversion from unsigned char * to const char *.
Is there another way to instantiate a QByteArray with the data?
the type casting is something you'll figure out. the more important thing you need to consider is that you DONT WANT to assume data returned from img.GetDataPointer() is a zero terminated c_str(). you better use a constructor with an explicit length value.
-
@jsulm said in Converting uint8_t data to a format that QByteArray can use?:
There are machines where a char consists of more than one byte though
Nope,
char
(both signed and unsigned) is the only type that is required by the standard to havesizeof()
equal to 1. Your architecture might use number of bits in a byte != 8 but char must always be 1 byte -
@jsulm said in Converting uint8_t data to a format that QByteArray can use?:
But if my machine defines a byte as 16bit what would uint8_t be then?
Never programmed GPU stuff so not sure how it's defined but would be very interesting if someone with a non-8-bits system could test it
-
@VRonin That's correct. But if my machine defines a byte as 16bit what would uint8_t be then?
https://stackoverflow.com/questions/13615764/is-a-byte-always-8-bits
In modern terms there are always 8 bits to a byte. This has been since 1993 IIRC. ISO/IEC 2382-1:1993.
At the end of the day I think it would be rare to find a machine today that was not based on 8 bits to a byte.Yes, a byte is always 8 bits in modern computing.
Are you really sure you have a 16-bit byte (not word)?? :)
-
@VRonin
I found that real surprising; you would have thought Googling forwindows ce byte size
would readily throw this up, but it does not. However, buried away I happenstanced across https://stackoverflow.com/a/5516161/489865Windows CE does roughly the same: its smallest type (at least with Microsoft's compiler) is 16 bits. They do not, however, treat a
char
as 16 bits -- instead they take the (non-conforming) approach of simply not supporting a type namedchar
at all.So you are right! However, given that then they apparently do not support
char
I would have thought that itself would create headaches...! :)