Re: [Development] unable to use lupdate(qt tools) in yocto sdk due to incorrect paths
Hi, On Fri, 2 Jun 2023 at 06:24, arslan.ahmad--- via Development wrote: > > > Changing Prefix to be a relative path would then break all qmake builds. > > do you see any possible workaround for this? Switching to CMake should do the trick I guess. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting feature freeze exception to container-assign epic
On Saturday, 3 June 2023 02:54:49 PDT Marc Mutz via Development wrote: > The container-assign epic is partially merged. What's left is > QString::assign(), and there only the assign(it, it) part. If we release > as-is (with step 1, cf. below), there's a gap in the QString::assign() > overload set vis-a-vis all other container classes (Qt or STL). Given it's partially done, I would support completing the feature. I would even go far enough to say that it's now not a *new* feature you're still be merging, but completing what you've already got in. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QPair vs std::pair difference with narrowing conversion
Den lör 3 juni 2023 kl 15:08 skrev Giuseppe D'Angelo :
>
>
>
> Il sab 3 giu 2023, 14:37 Elvis Stansvik ha scritto:
>>
>> Hi all,
>>
>> I was going through some legacy code and came across a behavioral
>> difference between QPair and std::pair:
>>
>> estan@edison:~$ cat test.cpp
>> #include
>> #include
>>
>> int main(void) {
>>int i = 1;
>>QPair{i, i};
>>std::pair{i, i};
>>return 0;
>> }
>> estan@edison:~$ g++ -isystem /usr/include/x86_64-linux-gnu/qt5
>> -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -Wall -fPIC -c
>> test.cpp
>> test.cpp: In function ‘int main()’:
>> test.cpp:6:31: warning: narrowing conversion of ‘i’ from ‘int’ to
>> ‘unsigned int’ [-Wnarrowing]
>>6 | QPair{i, i};
>> | ^
>> test.cpp:6:34: warning: narrowing conversion of ‘i’ from ‘int’ to
>> ‘unsigned int’ [-Wnarrowing]
>>6 | QPair{i, i};
>> | ^
>> estan@edison:~$
>>
>> Just curious if anyone know why what difference between QPair and
>> std::pair makes the narrowing conversion warning pop up in the QPair
>> case and not the std::pair case?
>
>
> Because QPair is lacking constructor 3
> https://en.cppreference.com/w/cpp/utility/pair/pair
>
> https://codebrowser.dev/qt5/qtbase/src/corelib/tools/qpair.h.html
>
> That constructor hides the narrowing into std::pair's code.
Ah yes, thanks!
>
>
>>
>> Note the warning only appears when using aggregate initialization with { }.
>
>
> It's list initialization, but it's not aggregate initialization, neither
> class is an aggregate as they have user defined constructors.
Right, my bad, had the terminology wrong.
>
>
>>
>> Using GCC 11.3.0 and Qt 5.15.3.
>
>
>
> Note: I made QPair an alias to std::pair in Qt 6.
Nice, thanks.
Elvis
>
> Hth,
>
>>
>> Cheers,
>> Elvis
>> --
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QPair vs std::pair difference with narrowing conversion
Il sab 3 giu 2023, 14:37 Elvis Stansvik ha scritto:
> Hi all,
>
> I was going through some legacy code and came across a behavioral
> difference between QPair and std::pair:
>
> estan@edison:~$ cat test.cpp
> #include
> #include
>
> int main(void) {
>int i = 1;
>QPair{i, i};
>std::pair{i, i};
>return 0;
> }
> estan@edison:~$ g++ -isystem /usr/include/x86_64-linux-gnu/qt5
> -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -Wall -fPIC -c
> test.cpp
> test.cpp: In function ‘int main()’:
> test.cpp:6:31: warning: narrowing conversion of ‘i’ from ‘int’ to
> ‘unsigned int’ [-Wnarrowing]
>6 | QPair{i, i};
> | ^
> test.cpp:6:34: warning: narrowing conversion of ‘i’ from ‘int’ to
> ‘unsigned int’ [-Wnarrowing]
>6 | QPair{i, i};
> | ^
> estan@edison:~$
>
> Just curious if anyone know why what difference between QPair and
> std::pair makes the narrowing conversion warning pop up in the QPair
> case and not the std::pair case?
>
Because QPair is lacking constructor 3
https://en.cppreference.com/w/cpp/utility/pair/pair
https://codebrowser.dev/qt5/qtbase/src/corelib/tools/qpair.h.html
That constructor hides the narrowing into std::pair's code.
> Note the warning only appears when using aggregate initialization with { }.
>
It's list initialization, but it's not aggregate initialization, neither
class is an aggregate as they have user defined constructors.
> Using GCC 11.3.0 and Qt 5.15.3.
>
Note: I made QPair an alias to std::pair in Qt 6.
Hth,
> Cheers,
> Elvis
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] QPair vs std::pair difference with narrowing conversion
Hi all,
I was going through some legacy code and came across a behavioral
difference between QPair and std::pair:
estan@edison:~$ cat test.cpp
#include
#include
int main(void) {
int i = 1;
QPair{i, i};
std::pair{i, i};
return 0;
}
estan@edison:~$ g++ -isystem /usr/include/x86_64-linux-gnu/qt5
-isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -Wall -fPIC -c
test.cpp
test.cpp: In function ‘int main()’:
test.cpp:6:31: warning: narrowing conversion of ‘i’ from ‘int’ to
‘unsigned int’ [-Wnarrowing]
6 | QPair{i, i};
| ^
test.cpp:6:34: warning: narrowing conversion of ‘i’ from ‘int’ to
‘unsigned int’ [-Wnarrowing]
6 | QPair{i, i};
| ^
estan@edison:~$
Just curious if anyone know why what difference between QPair and
std::pair makes the narrowing conversion warning pop up in the QPair
case and not the std::pair case?
Note the warning only appears when using aggregate initialization with { }.
Using GCC 11.3.0 and Qt 5.15.3.
Cheers,
Elvis
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Requesting feature freeze exception to container-assign epic
Hi, The container-assign epic is partially merged. What's left is QString::assign(), and there only the assign(it, it) part. If we release as-is (with step 1, cf. below), there's a gap in the QString::assign() overload set vis-a-vis all other container classes (Qt or STL). The QString::assign() overload set is constructed in four steps: - 1: non-(it,it) overloads (approved before the FF, but still doing its rounds on the CI for actual merging) - 2: (it, it) for QChar, QLatin1Char, char16_t (on Gerrit for review) - 3: ditto for char32_t (ditto, on Gerrit) - 4: ditto for (signed,unsigned) char, char8_t (not on Gerrit, yet) Each step adds value: Step 1 gives QString at least a contiguous-range overload. Step 2 makes QString pass tst_containerapisymmetry tests for assign(). Step 3 enables assign() functionality for UCS4-encoded data and Step 4 for UTF-8 encoded data that's not contiguous. The fourth step ran into a cyclic dependency issue with QStringDecoder, which depends on QString, and we need it vice versa. Given that non-contiguous UTF-8 data should be pretty rare, I'd be fine with cutting off after Step 3 for Qt 6.6 and adding Step 4 after the necessary refactorings (if any) for 6.7. I wouldn't like to stop after Step 2, because in that state the assign(it,it) function has an implied post-condition of result.size() == std::distance(first, last), which users should not come to rely on (Hyrum's Law), and Step 3 breaks that. Chain ends in https://codereview.qt-project.org/c/qt/qtbase/+/481544. Epic: https://bugreports.qt.io/browse/QTBUG-106165 Thanks, Marc -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
