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-pro
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 v
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
>> #in
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::p
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-li
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(
