Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Special Interest Groups
  3. C++ Gurus
  4. Qt6 C++ compilation changes

Qt6 C++ compilation changes

Scheduled Pinned Locked Moved Unsolved C++ Gurus
17 Posts 6 Posters 1.9k Views
  • 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.
  • JonBJ JonB

    @sierdzio
    Thanks, this sparked me to investigate. I happened to be using QJsonArray::count() as the function being passed to std::max(jsonArray.count(), 10).

    • https://doc.qt.io/qt-5/qjsonarray.html#count: int QJsonArray::count() const
    • https://doc.qt.io/qt-6/qjsonarray.html#count: qsizetype QJsonArray::count() const

    So at Qt6 it changed from int to qsizetype. This also answers @Christian-Ehrlicher as to why (without me being 32-bit). Hence the error at Qt6 but not at Qt5.....

    Now then. This change has been made throughout Qt6, e.g. QList::count() has moved from int to qsizetype similarly. That means potentially I will have a number of similar issues as & when I move other code from Qt5 to Qt6.... :(

    [BTW: Searching for changes from Qt5 to Qt6. I have no trouble finding lists of new or removed functions. I am unable to find where changes are documented for existing functions, such as this change in return types? Anywhere.]

    JoeCFDJ Offline
    JoeCFDJ Offline
    JoeCFD
    wrote on last edited by JoeCFD
    #8

    @JonB Here QVector, QList?

    QList's (and hence QVector's) size type is changed from int to qsizetype. Together with the size type, all relevant methods' signatures are updated to use qsizetype. This allows QList to hold more than 2^31 items on 64 bit platforms.

    1 Reply Last reply
    1
    • JonBJ JonB

      I am moving existing code which compiles fine under Qt5.15, gcc 11.4.0, -std=gnu++1z (C++17) to Qt6, gcc 13.2.0, also -std=gnu++1z.

      I have a couple of errors in new Qt6 vs Qt5 compilation for which I would like to know the actual reason. I have a correction/workaround in each case but I should still like to understand what the difference is to improve my C++ knowledge. It happens that both of these relate to "implicit type conversion" rules which I clearly don't know fully.

      First qsizetype:

      std::max(function_returning_qsizetype(), 10)
      >> error: no matching function for call to ‘max(qsizetype, int)’
      

      I now have change to:

      std::max(function_returning_qsizetype(), 10LL)
      

      Why did 10 used to work but now requires 10LL? Note that

      qsizetype st{10} /* or st(10) */;
      std::max(function_returning_qsizetype(), st)
      

      works, so at some level we can assign 10 to a qsizetype.

      Second QFlags<...> to QVariant:
      Returning a value from QVariant QAbstractItemModel::data()

      case Qt::TextAlignmentRole:
          return Qt::AlignHCenter | Qt::AlignVCenter;
      >> could not convert ‘Qt::operator|(Qt::AlignHCenter, Qt::AlignVCenter)’ from ‘QFlags<Qt::AlignmentFlag>’ to ‘QVariant’
      

      Note that:

          QFlags<Qt::AlignmentFlag> fl(Qt::AlignHCenter | Qt::AlignVCenter);
          return fl;
      

      doesn't help, same error on return statement.

      I now have change to:

      return QVariant(Qt::AlignHCenter | Qt::AlignVCenter);
      

      Why do I now need to cast/construct explicitly? Also why does

      return Qt::AlignCenter;
      

      work OK (without QVariant(...)) given the definition is

      enum AlignmentFlag {
      ...
      AlignCenter = AlignVCenter | AlignHCenter
      };
      Q_DECLARE_FLAGS(Alignment, AlignmentFlag)
      
      S Offline
      S Offline
      SimonSchroeder
      wrote on last edited by
      #9

      @JonB said in Qt6 C++ compilation changes:

      std::max(function_returning_qsizetype(), 10LL)

      Using 10LL is not portable. I don't really remember which type had this problem, but I once ran into a problem with these integer literals that did not have a solution for Windows, Linux, and macOS (yet). Starting from C++23 you have Z available which will be actually be portable for this use case (https://en.cppreference.com/w/cpp/language/integer_literal).

      JonBJ 1 Reply Last reply
      0
      • S SimonSchroeder

        @JonB said in Qt6 C++ compilation changes:

        std::max(function_returning_qsizetype(), 10LL)

        Using 10LL is not portable. I don't really remember which type had this problem, but I once ran into a problem with these integer literals that did not have a solution for Windows, Linux, and macOS (yet). Starting from C++23 you have Z available which will be actually be portable for this use case (https://en.cppreference.com/w/cpp/language/integer_literal).

        JonBJ Online
        JonBJ Online
        JonB
        wrote on last edited by JonB
        #10

        @SimonSchroeder
        What a mess trying to find a simple literal of the same type as something as basic as what QList::count() returns!

        For my part I only have to support gcc.

        I shan't be writing for (qsizetype i = 0LL; i < list.count(), I will be sticking with int. So one possibility would be to convert/cast the qsizetype to int for the std::max() so I can use a plain literal. But I think I will abandon std::max() for qMax() to avoid this ugliness.

        sierdzioS 1 Reply Last reply
        0
        • JonBJ JonB

          @SimonSchroeder
          What a mess trying to find a simple literal of the same type as something as basic as what QList::count() returns!

          For my part I only have to support gcc.

          I shan't be writing for (qsizetype i = 0LL; i < list.count(), I will be sticking with int. So one possibility would be to convert/cast the qsizetype to int for the std::max() so I can use a plain literal. But I think I will abandon std::max() for qMax() to avoid this ugliness.

          sierdzioS Offline
          sierdzioS Offline
          sierdzio
          Moderators
          wrote on last edited by
          #11

          I shan't be writing for (qsizetype i = 0LL; i < list.count(), I will be sticking with int.

          It might fail for very large lists ;-) But for (qsizetype i = 0; i < list.count() should work just fine.

          As for max, this is also an option if you like to type a lot:

          std::max(jsonArray.count(), static_cast<qsizetype>(10)).
          

          (Z(:^

          JonBJ 1 Reply Last reply
          0
          • sierdzioS sierdzio

            I shan't be writing for (qsizetype i = 0LL; i < list.count(), I will be sticking with int.

            It might fail for very large lists ;-) But for (qsizetype i = 0; i < list.count() should work just fine.

            As for max, this is also an option if you like to type a lot:

            std::max(jsonArray.count(), static_cast<qsizetype>(10)).
            
            JonBJ Online
            JonBJ Online
            JonB
            wrote on last edited by JonB
            #12

            @sierdzio said in Qt6 C++ compilation changes:

            It might fail for very large lists

            Absolutely! But as you can see the kind of size I have in mind is 10. That is a long way away from 2 ^ 63 :)

            static_cast<qsizetype>(10)

            Of course! But I am simply not prepared to write to write that when comparing against 10!

            JoeCFDJ 1 Reply Last reply
            0
            • JonBJ JonB

              @sierdzio said in Qt6 C++ compilation changes:

              It might fail for very large lists

              Absolutely! But as you can see the kind of size I have in mind is 10. That is a long way away from 2 ^ 63 :)

              static_cast<qsizetype>(10)

              Of course! But I am simply not prepared to write to write that when comparing against 10!

              JoeCFDJ Offline
              JoeCFDJ Offline
              JoeCFD
              wrote on last edited by
              #13

              @JonB This change matches the one in C++. I used to have loops like

              std::vector< something > vec;
              for ( unsigned idx = 0; idx < vec.size(); ++idx ) 
              {
              }
              

              In new C++

              std::vector< something > vec;
              for ( size_t idx = 0; idx < vec.size(); ++idx ) 
              {
              }
              

              If you do not like the casting, I guess you can replace your loop with

              for ( auto const & element : your list )
              {
              }
              

              Simpler.

              JonBJ 1 Reply Last reply
              0
              • JoeCFDJ JoeCFD

                @JonB This change matches the one in C++. I used to have loops like

                std::vector< something > vec;
                for ( unsigned idx = 0; idx < vec.size(); ++idx ) 
                {
                }
                

                In new C++

                std::vector< something > vec;
                for ( size_t idx = 0; idx < vec.size(); ++idx ) 
                {
                }
                

                If you do not like the casting, I guess you can replace your loop with

                for ( auto const & element : your list )
                {
                }
                

                Simpler.

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

                @JoeCFD
                I object to using size_t (should really be ssize_t which is what qsizetype is) as my "default" loop counter type when I have thousands of existing occurrences using int! (Having said that, just to be clear, the change in type/size does not prevent me from using int even now, so I don't have to change everything. It is something like std::max() which is affected/falls foul of the new definition.)

                Your last case is more or less what I use when iterating and I do not need the index inside the loop. But the integral counter is required/easier when you do need to know the index value.

                JoeCFDJ 1 Reply Last reply
                0
                • JonBJ JonB

                  @JoeCFD
                  I object to using size_t (should really be ssize_t which is what qsizetype is) as my "default" loop counter type when I have thousands of existing occurrences using int! (Having said that, just to be clear, the change in type/size does not prevent me from using int even now, so I don't have to change everything. It is something like std::max() which is affected/falls foul of the new definition.)

                  Your last case is more or less what I use when iterating and I do not need the index inside the loop. But the integral counter is required/easier when you do need to know the index value.

                  JoeCFDJ Offline
                  JoeCFDJ Offline
                  JoeCFD
                  wrote on last edited by JoeCFD
                  #15

                  @JonB from here
                  size(C++17)
                  ssize(C++20)
                  Something new for me. Good to know.

                  https://en.cppreference.com/w/cpp/iterator/size

                  Recently I built a project on Windows with C++ 14. size_t is needed to replace int for std::vector in the build warnings.

                  when you need an index

                  int index{}; (if you prefer int)
                  for ( auto const & element : your list )
                  {
                       do something with index
                       index++;
                  }
                  
                  JonBJ 1 Reply Last reply
                  0
                  • JoeCFDJ JoeCFD

                    @JonB from here
                    size(C++17)
                    ssize(C++20)
                    Something new for me. Good to know.

                    https://en.cppreference.com/w/cpp/iterator/size

                    Recently I built a project on Windows with C++ 14. size_t is needed to replace int for std::vector in the build warnings.

                    when you need an index

                    int index{}; (if you prefer int)
                    for ( auto const & element : your list )
                    {
                         do something with index
                         index++;
                    }
                    
                    JonBJ Online
                    JonBJ Online
                    JonB
                    wrote on last edited by JonB
                    #16

                    @JoeCFD
                    Sorry if you think I am being difficult, but I'm not going to write a "for-element-in-list" loop and then maintain a separate index counter! One or the other!

                    Besides I was talking about existing code already written. But as a I say I can still use an int loop counter at Qt6, at least with gcc, without warning. It's just something like std::max() which barfs.

                    We can debate further if you wish, but I do get that Qt etc. need to change to long long for size/count/array-indexing etc. I just don't like how messy it is making it (for std::max() at least) to pass a simple, numeric, non-qualified literal.

                    JoeCFDJ 1 Reply Last reply
                    0
                    • JonBJ JonB

                      @JoeCFD
                      Sorry if you think I am being difficult, but I'm not going to write a "for-element-in-list" loop and then maintain a separate index counter! One or the other!

                      Besides I was talking about existing code already written. But as a I say I can still use an int loop counter at Qt6, at least with gcc, without warning. It's just something like std::max() which barfs.

                      We can debate further if you wish, but I do get that Qt etc. need to change to long long for size/count/array-indexing etc. I just don't like how messy it is making it (for std::max() at least) to pass a simple, numeric, non-qualified literal.

                      JoeCFDJ Offline
                      JoeCFDJ Offline
                      JoeCFD
                      wrote on last edited by
                      #17

                      @JonB We learn more from discussions. I do not feel you are difficult in any way.

                      1 Reply Last reply
                      1

                      • Login

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