Converting uint8_t data to a format that QByteArray can use?

SGaist

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]

aha_1980

@Daniel-Williams

uint8_t is unsigned 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 if static_cast works for pointers, I think you need reinterpret_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

SGaist

@aha_1980 is correct, I wrote down the wrong cast type. Fixed it.

jsulm

@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

Kent-Dorfman

@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.

VRonin

@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 have sizeof() equal to 1. Your architecture might use number of bits in a byte != 8 but char must always be 1 byte

jsulm

@VRonin That's correct. But if my machine defines a byte as 16bit what would uint8_t be then?

VRonin

@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

JonB

@jsulm

@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

@JonB said in Converting uint8_t data to a format that QByteArray can use?:

Are you really sure you have a 16-bit byte (not word)??

Windows CE has 16bits as a minimum byte size AFAIK

JonB

@VRonin
I found that real surprising; you would have thought Googling for windows ce byte size would readily throw this up, but it does not. However, buried away I happenstanced across https://stackoverflow.com/a/5516161/489865

Windows 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 named char 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...! :)

Daniel Williams

@aha_1980 @SGaist You nailed it. The reinterpret_cast worked. Thank you!