Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Problem with a data from UDP
Forum Updated to NodeBB v4.3 + New Features

Problem with a data from UDP

Scheduled Pinned Locked Moved Solved General and Desktop
28 Posts 4 Posters 3.2k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J jenya7
    8 Jul 2021, 11:44

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

    K Offline
    K Offline
    KroMignon
    wrote on 8 Jul 2021, 11:44 last edited by KroMignon 7 Aug 2021, 11:45
    #21

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

    It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

    1 Reply Last reply
    2
    • J jenya7
      8 Jul 2021, 11:44

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

      J Offline
      J Offline
      JonB
      wrote on 8 Jul 2021, 11:44 last edited by JonB 7 Aug 2021, 11:51
      #22

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

      1 Reply Last reply
      0
      • J Offline
        J Offline
        jenya7
        wrote on 8 Jul 2021, 11:52 last edited by jenya7 7 Aug 2021, 12:02
        #23

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

        J K 2 Replies Last reply 8 Jul 2021, 11:54
        0
        • J jenya7
          8 Jul 2021, 11:52

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

          J Offline
          J Offline
          JonB
          wrote on 8 Jul 2021, 11:54 last edited by JonB 7 Aug 2021, 11:55
          #24

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

          1 Reply Last reply
          2
          • J jenya7
            8 Jul 2021, 11:52

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

            K Offline
            K Offline
            KroMignon
            wrote on 8 Jul 2021, 11:56 last edited by
            #25

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

            It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

            1 Reply Last reply
            0
            • K KroMignon
              8 Jul 2021, 11:40

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

              uint8_t* myPoint = static_cast<uint8_t*>(datagram.data());
              
              
              J Offline
              J Offline
              jenya7
              wrote on 8 Jul 2021, 12:00 last edited by jenya7 7 Aug 2021, 12:04
              #26

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

              uint8_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 but

              warning: use of old-style cast

              K 1 Reply Last reply 8 Jul 2021, 12:04
              0
              • J jenya7
                8 Jul 2021, 12:00

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

                uint8_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 but

                warning: use of old-style cast

                K Offline
                K Offline
                KroMignon
                wrote on 8 Jul 2021, 12:04 last edited by
                #27

                @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 not static_cast<>()

                It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

                J 1 Reply Last reply 8 Jul 2021, 12:06
                3
                • K KroMignon
                  8 Jul 2021, 12:04

                  @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 not static_cast<>()

                  J Offline
                  J Offline
                  jenya7
                  wrote on 8 Jul 2021, 12:06 last edited by jenya7 7 Aug 2021, 12:06
                  #28

                  @KroMignon said in Problem with a data from UDP:

                  reinterpret_cast

                  Thanks a lot. Looks like a great solution.

                  1 Reply Last reply
                  0

                  21/28

                  8 Jul 2021, 11:44

                  • Login

                  • Login or register to search.
                  21 out of 28
                  • First post
                    21/28
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • Users
                  • Groups
                  • Search
                  • Get Qt Extensions
                  • Unsolved