Problem with a data from UDP
-
@jenya7 said in Problem with a data from UDP:
his way - error: cannot initialize a parameter of type 'char *' with an rvalue of type 'uint8_t *' (aka 'unsigned char *')
What are you doing?
socketis as instance ofQUdpSocketandudp_bufferan instance ofQByteArrayor not?This must work, as I always do it!
QByteArray datagram(socket->pendingDatagramSize(), 0); QHostAddress sender; quint16 senderPort; socket->readDatagram(datagram.data(), datagram.size(), &sender, &senderPort);What are you doing?
socket is as instance of QUdpSocket and udp_buffer an instance of QByteArray or not?Yes it is.
But taking char by char form datagram.data()
I have to cast - uint8_t b0 = static_cast<uint8_t>(datagram[0]); -
What are you doing?
socket is as instance of QUdpSocket and udp_buffer an instance of QByteArray or not?Yes it is.
But taking char by char form datagram.data()
I have to cast - uint8_t b0 = static_cast<uint8_t>(datagram[0]);@jenya7 said in Problem with a data from UDP:
Yes it is.
But taking char by char form datagram.data()
I have to cast - byte b0 = static_cast<uint8_t>(datagram[0]);No:
for(const auto b : datagram) { qDebug() << "Byte value:" << quint8(b); }EDIT
oruint8_t* myPoint = static_cast<uint8_t*>(datagram.data()); -
What are you doing?
socket is as instance of QUdpSocket and udp_buffer an instance of QByteArray or not?Yes it is.
But taking char by char form datagram.data()
I have to cast - uint8_t b0 = static_cast<uint8_t>(datagram[0]);@jenya7
I will contribute one more time. I already told you what to do if you want to reduce repeated casting:If you don't like having to explicitly do casting each time, you could, say, write your own utility function for "the i'th element of a QByteArray as unsigned char/uint_t", or the whole data as uint_t *.
Same applies anywhere else.
For the record: I believe there have been discussions over the years about how some people would have preferred
QByteArrayto holdunsigned chars instead ofchars. It stays withchars due (at least partly) to it's (slightly weird) determination to end the data with\0and allow it to interchange fairly free withQString. This is not convenient for your case, but it is what it is, so you're going to have to work with it. -
@jenya7
I will contribute one more time. I already told you what to do if you want to reduce repeated casting:If you don't like having to explicitly do casting each time, you could, say, write your own utility function for "the i'th element of a QByteArray as unsigned char/uint_t", or the whole data as uint_t *.
Same applies anywhere else.
For the record: I believe there have been discussions over the years about how some people would have preferred
QByteArrayto holdunsigned chars instead ofchars. It stays withchars due (at least partly) to it's (slightly weird) determination to end the data with\0and allow it to interchange fairly free withQString. This is not convenient for your case, but it is what it is, so you're going to have to work with it.@JonB said in Problem with a data from UDP:
@jenya7
I will contribute one more time. I already told you what to do if you want to reduce repeated casting:If you don't like having to explicitly do casting each time, you could, say, write your own utility function for "the i'th element of a QByteArray as unsigned char/uint_t", or the whole data as uint_t *.
Same applies anywhere else.
To cast each element in a loop? It makes even worse, waste of run time.
-
@JonB said in Problem with a data from UDP:
@jenya7
I will contribute one more time. I already told you what to do if you want to reduce repeated casting:If you don't like having to explicitly do casting each time, you could, say, write your own utility function for "the i'th element of a QByteArray as unsigned char/uint_t", or the whole data as uint_t *.
Same applies anywhere else.
To cast each element in a loop? It makes even worse, waste of run time.
-
@JonB said in Problem with a data from UDP:
@jenya7
I will contribute one more time. I already told you what to do if you want to reduce repeated casting:If you don't like having to explicitly do casting each time, you could, say, write your own utility function for "the i'th element of a QByteArray as unsigned char/uint_t", or the whole data as uint_t *.
Same applies anywhere else.
To cast each element in a loop? It makes even worse, waste of run time.
@jenya7
No, I already explained it's to get rid of the explicit cast each time you access it. At some point you have to cast because of the different types, but you can reduce how often you do that. I don't know what else to say. This is straightforward C++ stuff. Oh, and as @KroMignon says, static casting has no runtime code. -
@JonB said in Problem with a data from UDP:
For the record: I believe there have been discussions over the years about how some people would have preferred QByteArray to hold unsigned chars instead of chars. It stays with chars due (at least partly) to it's (slightly weird) determination to end the data with \0 and allow it to interchange fairly free with QString. This is not convenient for your case, but it is what it is, so you're going to have to work with it.
Every embedded stack like LWIP, uIP and others - point to (uint8_t *).
Visual Studio - point to (uint8_t *).
VxWorks - point to (uint8_t *).
Don't remember any project I worked with TCP/UDP and got a string. And if it has to be a string it's very ease - strlen((char *) bytes) - strlen doesn't accuse me - error: cannot initialize a parameter of type... -
@JonB said in Problem with a data from UDP:
For the record: I believe there have been discussions over the years about how some people would have preferred QByteArray to hold unsigned chars instead of chars. It stays with chars due (at least partly) to it's (slightly weird) determination to end the data with \0 and allow it to interchange fairly free with QString. This is not convenient for your case, but it is what it is, so you're going to have to work with it.
Every embedded stack like LWIP, uIP and others - point to (uint8_t *).
Visual Studio - point to (uint8_t *).
VxWorks - point to (uint8_t *).
Don't remember any project I worked with TCP/UDP and got a string. And if it has to be a string it's very ease - strlen((char *) bytes) - strlen doesn't accuse me - error: cannot initialize a parameter of type...@jenya7
Jenya, what is your point here? Qt is written as it is. What do you want me or anyone to do about it because you don't like it or it works differently from something else?I've suggested some typing-saving workarounds for you, up to you whether you take advantage or ignore them. It's your code.
-
@JonB said in Problem with a data from UDP:
For the record: I believe there have been discussions over the years about how some people would have preferred QByteArray to hold unsigned chars instead of chars. It stays with chars due (at least partly) to it's (slightly weird) determination to end the data with \0 and allow it to interchange fairly free with QString. This is not convenient for your case, but it is what it is, so you're going to have to work with it.
Every embedded stack like LWIP, uIP and others - point to (uint8_t *).
Visual Studio - point to (uint8_t *).
VxWorks - point to (uint8_t *).
Don't remember any project I worked with TCP/UDP and got a string. And if it has to be a string it's very ease - strlen((char *) bytes) - strlen doesn't accuse me - error: cannot initialize a parameter of type...@jenya7 said in Problem with a data from UDP:
Every embedded stack like LWIP, uIP and others - point to (uint8_t *).
Visual Studio - point to (uint8_t *).
VxWorks - point to (uint8_t *).
Don't remember any project I worked with TCP/UDP and got string. Ans if it has to be string it's very ease - strlen((char *) bytes) - strlen doesn't accuse me - error: cannot initialize a parameter of type...Maybe, but your are using Qt, so you have to adapt your code to Qt or use another framework.
-
@jenya7 said in Problem with a data from UDP:
Yes it is.
But taking char by char form datagram.data()
I have to cast - byte b0 = static_cast<uint8_t>(datagram[0]);No:
for(const auto b : datagram) { qDebug() << "Byte value:" << quint8(b); }EDIT
oruint8_t* myPoint = static_cast<uint8_t*>(datagram.data());@KroMignon said in Problem with a data from UDP:
@jenya7 said in Problem with a data from UDP:
Yes it is.
But taking char by char form datagram.data()
I have to cast - byte b0 = static_cast<uint8_t>(datagram[0]);No:
for(const auto b : datagram) { qDebug() << "Byte value:" << quint8(b); }EDIT
oruint8_t* myPoint = static_cast<uint8_t*>(datagram.data());That's good! - uint8_t* myPoint = static_cast<uint8_t*>(datagram.data());
but
uint32_t MSGPARSER::ParseMessage(QByteArray data, MESSAGE * sens_msg) { uint8_t *data_u8 = static_cast<uint8_t*>(data.data()); }I get
error: static_cast from 'char *' to 'uint8_t *' (aka 'unsigned char *') is not allowed
This way
uint8_t data_u8 = (uint8_t)(data.data());
no error butwarning: use of old-style cast
-
@KroMignon said in Problem with a data from UDP:
@jenya7 said in Problem with a data from UDP:
Yes it is.
But taking char by char form datagram.data()
I have to cast - byte b0 = static_cast<uint8_t>(datagram[0]);No:
for(const auto b : datagram) { qDebug() << "Byte value:" << quint8(b); }EDIT
oruint8_t* myPoint = static_cast<uint8_t*>(datagram.data());That's good! - uint8_t* myPoint = static_cast<uint8_t*>(datagram.data());
but
uint32_t MSGPARSER::ParseMessage(QByteArray data, MESSAGE * sens_msg) { uint8_t *data_u8 = static_cast<uint8_t*>(data.data()); }I get
error: static_cast from 'char *' to 'uint8_t *' (aka 'unsigned char *') is not allowed
This way
uint8_t data_u8 = (uint8_t)(data.data());
no error butwarning: use of old-style cast
-
@jenya7 said in Problem with a data from UDP:
error: static_cast from 'char *' to 'uint8_t *' (aka 'unsigned char *') is not allowed
Sorry, I am a little bit tired today.. should be
reinterpret_cast<>()and notstatic_cast<>()@KroMignon said in Problem with a data from UDP:
reinterpret_cast
Thanks a lot. Looks like a great solution.
