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. QByteArray and char type
Forum Updated to NodeBB v4.3 + New Features

QByteArray and char type

Scheduled Pinned Locked Moved Solved General and Desktop
58 Posts 9 Posters 11.6k Views 4 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.HilkJ J.Hilk

    @JonB said in QByteArray and char type:

    So, off topic, but: in view of this, would you, @J-Hilk, or others, advise me to revert to the default of Clang being on? :)

    IMHO the inclusion/support for clang as greatly improved, since its first introduction.
    In the beginning, I also turned it of, and for about a year or so it's on by default (for me). And for me I had more positive experience with it then (hardly any) negative ones.

    So, turn it on:D

    JonBJ Offline
    JonBJ Offline
    JonB
    wrote on last edited by JonB
    #14

    @J-Hilk
    Thanks for advice. This is all @mrjj's fault ;-)

    Then I have a question (to which I suspect I already know the answer, unfortunately). I use method-name completion all the time. Without Clang on the suggestions are alphabetical, which is good to navigate. But with Clang (last time I looked, anyway) the order is "pseudo-random" ;-) Algorithm for ordering might make sense to a machine, but not to a human.... Do you not find this an issue?

    J.HilkJ 1 Reply Last reply
    0
    • JonBJ JonB

      @J-Hilk
      Thanks for advice. This is all @mrjj's fault ;-)

      Then I have a question (to which I suspect I already know the answer, unfortunately). I use method-name completion all the time. Without Clang on the suggestions are alphabetical, which is good to navigate. But with Clang (last time I looked, anyway) the order is "pseudo-random" ;-) Algorithm for ordering might make sense to a machine, but not to a human.... Do you not find this an issue?

      J.HilkJ Offline
      J.HilkJ Offline
      J.Hilk
      Moderators
      wrote on last edited by
      #15

      @JonB it still does that, I'm not sure why and you could probably make your own plugin to sort it before showing if it really bothers you :D

      But usually I know the beginning of the method so I type the first 2 letters which usually is enough to narrow the selection down to a hand full of options 😉


      Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


      Q: What's that?
      A: It's blue light.
      Q: What does it do?
      A: It turns blue.

      1 Reply Last reply
      0
      • JonBJ JonB

        I was struck by something when reading @stretchthebits comment at https://forum.qt.io/topic/118343/qbytearray-range-issue/8

        QByteArray seems to be just an array of char, which are signed values.

        In other words, the range is from -128 to 127.

        My immediate reaction was: this must be wrong, it will be an array of unsigned char. But he is correct, and it has methods like char() which return char *, and nothing native which deals with unsigned char *.

        Now, I understand this is convenient because it is used to interact fairly seamlessly with char arrays and QString types. However, that is not what "byte" means, and in all other languages/toolkits which use a "byte" type that is always an unsigned 8-bit char type.

        There may not be much to say about my observation, but I am surprised Qt has chosen to call a signed char type QByteArray. That seems to me a misnomer, and its usage is "unusual". It also means that I don't see any Qt type for natively handling byte/unsigned char type, you have to do casting? Which also surprises me among all the convenience types that Qt does provide.

        Any comments from the Qt experts?

        JKSHJ Offline
        JKSHJ Offline
        JKSH
        Moderators
        wrote on last edited by
        #16

        @JonB said in QByteArray and char type:

        I am surprised Qt has chosen to call a signed char type QByteArray.

        Be aware that char and signed char are different types in C++: https://stackoverflow.com/questions/436513/char-signed-char-char-unsigned-char . int is guaranteed to be signed but char is not!

        For ARM CPUs, char is unsigned by default: https://developer.arm.com/documentation/dui0491/i/C-and-C---Implementation-Details/Character-sets-and-identifiers -- "The ARM ABI defines char as an unsigned byte, and this is the interpretation used by the C++ libraries supplied with the ARM compilation tools"

        Seems Qt would have been better naming it QCharArray, since that is more accurate than QByteArray, by normal naming conventions.

        I'd say @aha_1980's "QDataArray" name would work better than "QCharArray". To me, a "char array" is more related to historical text strings than binary data... and QByteArray is intended to be a container of binary data (i.e. bytes). I have no problems with its current name; I just treat the char as an implementation detail (albeit a leaky one)

        This (or similar code) is the danger of the existing implementation being used by someone, unaware that they will not produce what is (presumably) the "expected" result, given that he assumes he is dealing with "bytes".

        What is the meaning of doing an inequality comparison between a byte and a number? 127 is not a byte.

        they could introduce, say, a byte() method to correspond to the current data() method, to return unsigned char * instead of char *.

        I don't see much point in switching from char to unsigned char. If we're to initiate a switch, let's do things properly and switch to std::byte.

        Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

        JonBJ J.HilkJ 2 Replies Last reply
        2
        • JKSHJ JKSH

          @JonB said in QByteArray and char type:

          I am surprised Qt has chosen to call a signed char type QByteArray.

          Be aware that char and signed char are different types in C++: https://stackoverflow.com/questions/436513/char-signed-char-char-unsigned-char . int is guaranteed to be signed but char is not!

          For ARM CPUs, char is unsigned by default: https://developer.arm.com/documentation/dui0491/i/C-and-C---Implementation-Details/Character-sets-and-identifiers -- "The ARM ABI defines char as an unsigned byte, and this is the interpretation used by the C++ libraries supplied with the ARM compilation tools"

          Seems Qt would have been better naming it QCharArray, since that is more accurate than QByteArray, by normal naming conventions.

          I'd say @aha_1980's "QDataArray" name would work better than "QCharArray". To me, a "char array" is more related to historical text strings than binary data... and QByteArray is intended to be a container of binary data (i.e. bytes). I have no problems with its current name; I just treat the char as an implementation detail (albeit a leaky one)

          This (or similar code) is the danger of the existing implementation being used by someone, unaware that they will not produce what is (presumably) the "expected" result, given that he assumes he is dealing with "bytes".

          What is the meaning of doing an inequality comparison between a byte and a number? 127 is not a byte.

          they could introduce, say, a byte() method to correspond to the current data() method, to return unsigned char * instead of char *.

          I don't see much point in switching from char to unsigned char. If we're to initiate a switch, let's do things properly and switch to std::byte.

          JonBJ Offline
          JonBJ Offline
          JonB
          wrote on last edited by JonB
          #17

          @JKSH said in QByteArray and char type:
          I was not aware that char is no longer defined as signed (God bless C). Thank you for pointing that out.

          What is the meaning of doing an inequality comparison between a byte and a number? 127 is not a byte.

          Given the use of the word "byte" in QByteArray, I am (arrogantly) confident that since

              QByteArray b;
              b.resize(1);
              b[0] = 128;
              if (b.at(0) >= 127)
                  qDebug() << "Yes";
          

          goes through gcc without warning and does not produce "Yes" it will catch people out, if I could look through a whole bunch of people's code.... It's an observation. In part inspired from the confusion shown in the https://forum.qt.io/topic/118343/qbytearray-range-issue thread.

          1 Reply Last reply
          0
          • JKSHJ JKSH

            @JonB said in QByteArray and char type:

            I am surprised Qt has chosen to call a signed char type QByteArray.

            Be aware that char and signed char are different types in C++: https://stackoverflow.com/questions/436513/char-signed-char-char-unsigned-char . int is guaranteed to be signed but char is not!

            For ARM CPUs, char is unsigned by default: https://developer.arm.com/documentation/dui0491/i/C-and-C---Implementation-Details/Character-sets-and-identifiers -- "The ARM ABI defines char as an unsigned byte, and this is the interpretation used by the C++ libraries supplied with the ARM compilation tools"

            Seems Qt would have been better naming it QCharArray, since that is more accurate than QByteArray, by normal naming conventions.

            I'd say @aha_1980's "QDataArray" name would work better than "QCharArray". To me, a "char array" is more related to historical text strings than binary data... and QByteArray is intended to be a container of binary data (i.e. bytes). I have no problems with its current name; I just treat the char as an implementation detail (albeit a leaky one)

            This (or similar code) is the danger of the existing implementation being used by someone, unaware that they will not produce what is (presumably) the "expected" result, given that he assumes he is dealing with "bytes".

            What is the meaning of doing an inequality comparison between a byte and a number? 127 is not a byte.

            they could introduce, say, a byte() method to correspond to the current data() method, to return unsigned char * instead of char *.

            I don't see much point in switching from char to unsigned char. If we're to initiate a switch, let's do things properly and switch to std::byte.

            J.HilkJ Offline
            J.HilkJ Offline
            J.Hilk
            Moderators
            wrote on last edited by J.Hilk
            #18

            @JKSH said in QByteArray and char type:

            I don't see much point in switching from char to unsigned char. If we're to initiate a switch, let's do things properly and switch to std::byte.

            is someone(tm) where to make the changes, like @aha_1980 suggested in this bug report: https://bugreports.qt.io/browse/QTBUG-64746

            you would prefer std::byte over unsigned char ?

            Because Thiago was against scope creep, and adding std::byte and unsigned char probably falls in that category


            that said, std::byte would make that Qt Version require c++17 or later. I'm not sure, that's ok, or not ?


            Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


            Q: What's that?
            A: It's blue light.
            Q: What does it do?
            A: It turns blue.

            aha_1980A JKSHJ 2 Replies Last reply
            0
            • J.HilkJ J.Hilk

              @JKSH said in QByteArray and char type:

              I don't see much point in switching from char to unsigned char. If we're to initiate a switch, let's do things properly and switch to std::byte.

              is someone(tm) where to make the changes, like @aha_1980 suggested in this bug report: https://bugreports.qt.io/browse/QTBUG-64746

              you would prefer std::byte over unsigned char ?

              Because Thiago was against scope creep, and adding std::byte and unsigned char probably falls in that category


              that said, std::byte would make that Qt Version require c++17 or later. I'm not sure, that's ok, or not ?

              aha_1980A Offline
              aha_1980A Offline
              aha_1980
              Lifetime Qt Champion
              wrote on last edited by
              #19

              Good morning @J-Hilk,

              that said, std::byte would make that Qt Version require c++17 or later. I'm not sure, that's ok, or not ?

              That is no problem, as Qt 6 requires C++17.

              But as std::byte is also with limited scope (no arithmetic) I'm not sure it is a general solution...

              Qt has to stay free or it will die.

              J.HilkJ 1 Reply Last reply
              0
              • aha_1980A aha_1980

                Good morning @J-Hilk,

                that said, std::byte would make that Qt Version require c++17 or later. I'm not sure, that's ok, or not ?

                That is no problem, as Qt 6 requires C++17.

                But as std::byte is also with limited scope (no arithmetic) I'm not sure it is a general solution...

                J.HilkJ Offline
                J.HilkJ Offline
                J.Hilk
                Moderators
                wrote on last edited by
                #20

                @aha_1980 good morning to you too!

                That is no problem, as Qt 6 requires C++17.

                where did you get that from ? I spend like 30 min searching for any reference and didn't find anything :(


                Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                Q: What's that?
                A: It's blue light.
                Q: What does it do?
                A: It turns blue.

                aha_1980A 1 Reply Last reply
                0
                • J.HilkJ J.Hilk

                  @aha_1980 good morning to you too!

                  That is no problem, as Qt 6 requires C++17.

                  where did you get that from ? I spend like 30 min searching for any reference and didn't find anything :(

                  aha_1980A Offline
                  aha_1980A Offline
                  aha_1980
                  Lifetime Qt Champion
                  wrote on last edited by
                  #21

                  Hi @J-Hilk ,

                  we've missed you at 2019 Contributers summit ;)

                  https://wiki.qt.io/Qt_Contributors_Summit_2019_Program#C.2B.2B17_language_and_std_library_features_for_Qt_6

                  Qt has to stay free or it will die.

                  1 Reply Last reply
                  1
                  • J.HilkJ J.Hilk

                    @JKSH said in QByteArray and char type:

                    I don't see much point in switching from char to unsigned char. If we're to initiate a switch, let's do things properly and switch to std::byte.

                    is someone(tm) where to make the changes, like @aha_1980 suggested in this bug report: https://bugreports.qt.io/browse/QTBUG-64746

                    you would prefer std::byte over unsigned char ?

                    Because Thiago was against scope creep, and adding std::byte and unsigned char probably falls in that category


                    that said, std::byte would make that Qt Version require c++17 or later. I'm not sure, that's ok, or not ?

                    JKSHJ Offline
                    JKSHJ Offline
                    JKSH
                    Moderators
                    wrote on last edited by
                    #22

                    @J-Hilk said in QByteArray and char type:

                    @JKSH said in QByteArray and char type:

                    I don't see much point in switching from char to unsigned char. If we're to initiate a switch, let's do things properly and switch to std::byte.

                    is someone(tm) where to make the changes, like @aha_1980 suggested in this bug report: https://bugreports.qt.io/browse/QTBUG-64746

                    you would prefer std::byte over unsigned char ?

                    Actually, I take that back. I just tried playing std::byte and found that it's not easy to work with:

                    std::byte b = 0xFF; // Error: cannot initialize a variable of type 'std::byte' with an rvalue of type 'int'
                    
                    auto x = std::byte{0xFF};
                    auto y = uchar{0xFF};
                    qDebug() << (x == y); // Error: Invalid operands to binary expression
                    

                    We also can't pass std::byte to a function that expects unsigned char without casting, so it isn't any more interoperable than the existing char.

                    Because Thiago was against scope creep, and adding std::byte and unsigned char probably falls in that category

                    I was originally thinking of adding functions that operate on std::byte and omitting functions that operate on unsigned char. I'm no longer convinced that's helpful.

                    std::byte would make that Qt Version require c++17 or later. I'm not sure, that's ok, or not ?

                    As @aha_1980 pointed out, this part isn't an issue.

                    The bigger issue is reaching a consensus on how far we should go:

                    • Thiago Maciera wants to keep things as-is but is open to letting "someone(TM)" add a few convenience functions for interop with unsigned char.
                    • Marc Mutz wants to rework QByteArray completely to use std::byte under the hood: https://lists.qt-project.org/pipermail/development/2020-May/039532.html

                    @aha_1980 said in QByteArray and char type:

                    Hi @J-Hilk ,

                    we've missed you at 2019 Contributers summit ;)

                    https://wiki.qt.io/Qt_Contributors_Summit_2019_Program#C.2B.2B17_language_and_std_library_features_for_Qt_6

                    There's also the blog post at https://www.qt.io/blog/first-qt-6.0-snapshot-available

                    P.S. Anyone signed up for the virtual Qt World Summit? :-D

                    Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                    JonBJ 1 Reply Last reply
                    3
                    • J.HilkJ Offline
                      J.HilkJ Offline
                      J.Hilk
                      Moderators
                      wrote on last edited by J.Hilk
                      #23

                      @JKSH alright, lets see if that "someone(TM)" ends up being me. Have to contribute eventually 🤷‍♂️

                      and yes I bought a ticket already ;)

                      @aha_1980

                      we've missed you at 2019 Contributers summit ;)

                      I'm not a source code contributor (yet :) )


                      Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                      Q: What's that?
                      A: It's blue light.
                      Q: What does it do?
                      A: It turns blue.

                      aha_1980A 1 Reply Last reply
                      2
                      • JKSHJ JKSH

                        @J-Hilk said in QByteArray and char type:

                        @JKSH said in QByteArray and char type:

                        I don't see much point in switching from char to unsigned char. If we're to initiate a switch, let's do things properly and switch to std::byte.

                        is someone(tm) where to make the changes, like @aha_1980 suggested in this bug report: https://bugreports.qt.io/browse/QTBUG-64746

                        you would prefer std::byte over unsigned char ?

                        Actually, I take that back. I just tried playing std::byte and found that it's not easy to work with:

                        std::byte b = 0xFF; // Error: cannot initialize a variable of type 'std::byte' with an rvalue of type 'int'
                        
                        auto x = std::byte{0xFF};
                        auto y = uchar{0xFF};
                        qDebug() << (x == y); // Error: Invalid operands to binary expression
                        

                        We also can't pass std::byte to a function that expects unsigned char without casting, so it isn't any more interoperable than the existing char.

                        Because Thiago was against scope creep, and adding std::byte and unsigned char probably falls in that category

                        I was originally thinking of adding functions that operate on std::byte and omitting functions that operate on unsigned char. I'm no longer convinced that's helpful.

                        std::byte would make that Qt Version require c++17 or later. I'm not sure, that's ok, or not ?

                        As @aha_1980 pointed out, this part isn't an issue.

                        The bigger issue is reaching a consensus on how far we should go:

                        • Thiago Maciera wants to keep things as-is but is open to letting "someone(TM)" add a few convenience functions for interop with unsigned char.
                        • Marc Mutz wants to rework QByteArray completely to use std::byte under the hood: https://lists.qt-project.org/pipermail/development/2020-May/039532.html

                        @aha_1980 said in QByteArray and char type:

                        Hi @J-Hilk ,

                        we've missed you at 2019 Contributers summit ;)

                        https://wiki.qt.io/Qt_Contributors_Summit_2019_Program#C.2B.2B17_language_and_std_library_features_for_Qt_6

                        There's also the blog post at https://www.qt.io/blog/first-qt-6.0-snapshot-available

                        P.S. Anyone signed up for the virtual Qt World Summit? :-D

                        JonBJ Offline
                        JonBJ Offline
                        JonB
                        wrote on last edited by
                        #24

                        @JKSH said in QByteArray and char type:

                        Actually, I take that back. I just tried playing std::byte and found that it's not easy to work with:

                        You guys know more about C++ than I, but my reading of std::byte() is that it is effectively just a representation of an 8-bit pattern. You are not supposed to do any arithmetic on it, or natively compare it to unsigned char etc. It's just a "blob" of data. ?

                        1 Reply Last reply
                        1
                        • JonBJ JonB

                          @J-Hilk , @aha_1980
                          Playing with QByteArrray, I now have a couple of observations/questions.

                              QByteArray b;
                              b.resize(1);
                              b[0] = 128;
                              if (b[0] >= 127)
                                  qDebug() << "Yes (1)";
                              if (b.at(0) >= 127)
                                  qDebug() << "Yes (2)";
                          

                          As an observation: neither of these outputs "Yes". This (or similar code) is the danger of the existing implementation being used by someone, unaware that they will not produce what is (presumably) the "expected" result, given that he assumes he is dealing with "bytes".

                          This produces a warning (gcc, 9.3.0) on the if (b[0] >= 127) line only:

                          ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second

                          [Don't know who wrote that message, but it's cryptic in the extreme!]

                          Question: why does [] produce this warning but at() does not?

                          JKSHJ Offline
                          JKSHJ Offline
                          JKSH
                          Moderators
                          wrote on last edited by JKSH
                          #25

                          @JonB said in QByteArray and char type:

                          my reading of std::byte() is that it is effectively just a representation of an 8-bit pattern.

                          I agree.

                          (Caveat: A byte is defined as the smallest accesible unit of data in memory. It's usually 8-bits in today's common architectures, but it doesn't actually have to be 8-bits)

                          You are not supposed to do any arithmetic on it

                          I agree. And I think programmers shouldn't normally try to do arithmetic on QByteArray elements either. (Exception: If you have a low-level efficiency hack in mind, you really know what you're doing, and you document it clearly, then go ahead)

                          ...or natively compare it to unsigned char etc. It's just a "blob" of data. ?

                          Wasn't your original point of this thread that a "blob" of data should be unsigned char?

                          Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                          JonBJ 1 Reply Last reply
                          0
                          • J.HilkJ J.Hilk

                            @JKSH alright, lets see if that "someone(TM)" ends up being me. Have to contribute eventually 🤷‍♂️

                            and yes I bought a ticket already ;)

                            @aha_1980

                            we've missed you at 2019 Contributers summit ;)

                            I'm not a source code contributor (yet :) )

                            aha_1980A Offline
                            aha_1980A Offline
                            aha_1980
                            Lifetime Qt Champion
                            wrote on last edited by
                            #26

                            @J-Hilk said in QByteArray and char type:

                            I'm not a source code contributor (yet :) )

                            I don't think that's a precondition. You contribute on many other places.

                            And you have a good knowledge about the library and a vision where it should go to.

                            And that's what counts :)

                            Regards

                            Qt has to stay free or it will die.

                            JKSHJ 1 Reply Last reply
                            3
                            • aha_1980A aha_1980

                              @J-Hilk said in QByteArray and char type:

                              I'm not a source code contributor (yet :) )

                              I don't think that's a precondition. You contribute on many other places.

                              And you have a good knowledge about the library and a vision where it should go to.

                              And that's what counts :)

                              Regards

                              JKSHJ Offline
                              JKSHJ Offline
                              JKSH
                              Moderators
                              wrote on last edited by
                              #27

                              @aha_1980 said in QByteArray and char type:

                              @J-Hilk said in QByteArray and char type:

                              I'm not a source code contributor (yet :) )

                              I don't think that's a precondition. You contribute on many other places.

                              And you have a good knowledge about the library and a vision where it should go to.

                              And that's what counts :)

                              +1 @J-Hilk is definitely a Contributor to the Qt community.

                              Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                              1 Reply Last reply
                              3
                              • JKSHJ JKSH

                                @JonB said in QByteArray and char type:

                                my reading of std::byte() is that it is effectively just a representation of an 8-bit pattern.

                                I agree.

                                (Caveat: A byte is defined as the smallest accesible unit of data in memory. It's usually 8-bits in today's common architectures, but it doesn't actually have to be 8-bits)

                                You are not supposed to do any arithmetic on it

                                I agree. And I think programmers shouldn't normally try to do arithmetic on QByteArray elements either. (Exception: If you have a low-level efficiency hack in mind, you really know what you're doing, and you document it clearly, then go ahead)

                                ...or natively compare it to unsigned char etc. It's just a "blob" of data. ?

                                Wasn't your original point of this thread that a "blob" of data should be unsigned char?

                                JonBJ Offline
                                JonBJ Offline
                                JonB
                                wrote on last edited by JonB
                                #28

                                @JKSH said in QByteArray and char type:

                                I agree. And I think programmers shouldn't try to do arithmetic on QByteArray elements either.

                                That's fine if I receive some QByteArray data and just want to store it/forward it onto something else. It's not fine if I need to look at its content and act on it for some purpose. Then I may need to, say, see if it's greater than 200 or whatever. At which point I think I need to cast away from std::byte() to achieve that.

                                Wasn't your original point of this thread that a "blob" of data should be unsigned char?

                                I was not the person who introduced the discussion about representing it via std::byte, for good or for bad! I want to be able to examine the bytes and do, for example, greater-then operations on them. For that, my original point was that I did not expect something referring to "bytes" --- using at least what I have found usage of that word in other languages to be, viz. an unsigned quantity in range 0--255 --- to have an interface only offering (signed) chars, I expected unsigned chars to be available. Else one must be careful about comparison code, for instance.

                                JKSHJ 1 Reply Last reply
                                0
                                • J.HilkJ Offline
                                  J.HilkJ Offline
                                  J.Hilk
                                  Moderators
                                  wrote on last edited by
                                  #29

                                  Let me bring even more confusion in this and point to Timur Doumler excellent talk at CppCon 2019 about type punning, where he outlines that this:

                                  void printBitRepresentation(float f)
                                  {
                                      auto buf* = reinterpret_cast<unsigned char*>(&f);
                                           for( int i(0); i < sizeof(float); i++ ) {
                                                  std::cout << buf[i];
                                           }
                                  }
                                  
                                  

                                  is actually undefined behavior.
                                  https://youtu.be/_qzMpk-22cc?t=2626

                                  @JKSH thanks :D


                                  Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                                  Q: What's that?
                                  A: It's blue light.
                                  Q: What does it do?
                                  A: It turns blue.

                                  JonBJ JKSHJ 2 Replies Last reply
                                  3
                                  • J.HilkJ J.Hilk

                                    Let me bring even more confusion in this and point to Timur Doumler excellent talk at CppCon 2019 about type punning, where he outlines that this:

                                    void printBitRepresentation(float f)
                                    {
                                        auto buf* = reinterpret_cast<unsigned char*>(&f);
                                             for( int i(0); i < sizeof(float); i++ ) {
                                                    std::cout << buf[i];
                                             }
                                    }
                                    
                                    

                                    is actually undefined behavior.
                                    https://youtu.be/_qzMpk-22cc?t=2626

                                    @JKSH thanks :D

                                    JonBJ Offline
                                    JonBJ Offline
                                    JonB
                                    wrote on last edited by JonB
                                    #30

                                    @J-Hilk
                                    I did have a look at that (frightening) discussion. I was "perturbed" by the answer that you have to rely on what he said was a "magic" implementation of memcpy(), which you can't know anything about, to achieve it! And didn't really understand how that resolves whatever the issue is anyway.

                                    J.HilkJ 1 Reply Last reply
                                    0
                                    • JonBJ JonB

                                      @J-Hilk
                                      I did have a look at that (frightening) discussion. I was "perturbed" by the answer that you have to rely on what he said was a "magic" implementation of memcpy(), which you can't know anything about, to achieve it! And didn't really understand how that resolves whatever the issue is anyway.

                                      J.HilkJ Offline
                                      J.HilkJ Offline
                                      J.Hilk
                                      Moderators
                                      wrote on last edited by
                                      #31

                                      @JonB well its a wording defect, I'm pretty sure all compilers behave the same here. It's just not explicitly defined 🤷‍♂️


                                      Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                                      Q: What's that?
                                      A: It's blue light.
                                      Q: What does it do?
                                      A: It turns blue.

                                      JonBJ 1 Reply Last reply
                                      0
                                      • J.HilkJ J.Hilk

                                        @JonB well its a wording defect, I'm pretty sure all compilers behave the same here. It's just not explicitly defined 🤷‍♂️

                                        JonBJ Offline
                                        JonBJ Offline
                                        JonB
                                        wrote on last edited by JonB
                                        #32

                                        @J-Hilk
                                        I still didn't understand how using memcpy() between addresses (void * received by memcpy()) resolved the problem, as opposed to just moving it elsewhere. Perhaps I would have had to read the whitepaper he showed if I wanted to understand. Unless you feel like explaining why memcpy() from one address to another, and then back in code accessing the destination address as an unsigned char * but not so for the source address, would make it "work correctly"...?

                                        J.HilkJ kshegunovK 2 Replies Last reply
                                        0
                                        • JonBJ JonB

                                          @J-Hilk
                                          I still didn't understand how using memcpy() between addresses (void * received by memcpy()) resolved the problem, as opposed to just moving it elsewhere. Perhaps I would have had to read the whitepaper he showed if I wanted to understand. Unless you feel like explaining why memcpy() from one address to another, and then back in code accessing the destination address as an unsigned char * but not so for the source address, would make it "work correctly"...?

                                          J.HilkJ Offline
                                          J.HilkJ Offline
                                          J.Hilk
                                          Moderators
                                          wrote on last edited by
                                          #33

                                          @JonB well as I understand it:

                                          reinterpret_cast does not change the pointer. You previously pointed to the float object, and after the reinterpret_cast you still do. And now you want to do pointer arithmetic on that object that is undefined behavior.

                                          Now with memcpy you actually copy the bytes from one pointer to an other. How thats done, only the compiler vendor knows :D but after the copy have defined behavior, because the char array is actually there!

                                          But it makes no difference
                                          take a look at this compiler explorer output

                                          https://gcc.godbolt.org/z/7673av

                                          the 2 functions produce identical assembler code


                                          Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                                          Q: What's that?
                                          A: It's blue light.
                                          Q: What does it do?
                                          A: It turns blue.

                                          JonBJ 1 Reply Last reply
                                          0

                                          • Login

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