Problem with a data from UDP
-
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]);wrote on 8 Jul 2021, 11:40 last edited by KroMignon 7 Aug 2021, 11:43@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]);wrote on 8 Jul 2021, 11:41 last edited by JonB 7 Aug 2021, 11:43@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
QByteArray
to holdunsigned char
s instead ofchar
s. It stays withchar
s due (at least partly) to it's (slightly weird) determination to end the data with\0
and 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
QByteArray
to holdunsigned char
s instead ofchar
s. It stays withchar
s due (at least partly) to it's (slightly weird) determination to end the data with\0
and 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.wrote on 8 Jul 2021, 11:44 last edited by@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.
wrote on 8 Jul 2021, 11:44 last edited by KroMignon 7 Aug 2021, 11:45@jenya7 said in Problem with a data from UDP:
To cast each element in a loop? It makes even worse, waste of run time.
Casting does not have any impact at runtime... it is only long to write!
-
@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.
wrote on 8 Jul 2021, 11:44 last edited by JonB 7 Aug 2021, 11:51@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. -
wrote on 8 Jul 2021, 11:52 last edited by jenya7 7 Aug 2021, 12:02
@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...wrote on 8 Jul 2021, 11:54 last edited by JonB 7 Aug 2021, 11:55@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...wrote on 8 Jul 2021, 11:56 last edited by@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());
wrote on 8 Jul 2021, 12:00 last edited by jenya7 7 Aug 2021, 12:04@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
wrote on 8 Jul 2021, 12:04 last edited by@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<>()
-
@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<>()
wrote on 8 Jul 2021, 12:06 last edited by jenya7 7 Aug 2021, 12:06@KroMignon said in Problem with a data from UDP:
reinterpret_cast
Thanks a lot. Looks like a great solution.
27/28