Qt6 C++ compilation changes

JonB

why did it work with Qt5. Did you use 32 bit there?

Absolutely not, 64-bit.

Was qsizetype defined as std::ssize_t at Qt5, did it change subtly at Qt6?

If not, gcc version has been upped (per my initial post) at my new Ubuntu 24.04, it might be that?

I still don't totally understand that e.g. ints (like an unqualified literal number) match longs but seemingly not long longs.

It's a pain to have to change literals like 10 to 10LL to use std::max(). Most Qt classes with count()/size() (like QList) return qsizetype/long long and will require this of me now/for existing code.

Christian Ehrlicher

@JonB said in Qt6 C++ compilation changes:

Was qsizetype defined as std::ssize_t at Qt5, did it change subtly at Qt6?

No, see the docs: https://doc.qt.io/qt-5/qtglobal.html#qsizetype-alias

sierdzio

qsizetype is used for container indexing and that DID change in Qt 6. In Qt 5 containers returned size() as int (so 32 bit on most platforms).

But if your function really retuned qsizetype in Qt 5 then I'm not entirely sure what's the deal.

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

ekkescorner

@JonB said in Qt6 C++ compilation changes:

Searching for changes from Qt5 to Qt6

here's my checklist what I found out while porting (mobile) apps from 5.15 to 6.7:
https://t1p.de/ekkeChecklist

JoeCFD

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

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

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.

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

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!

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.

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.

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++;
}

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.

JoeCFD

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