Re: [Development] QDateTime is missing shared null optimization

[Sergio Martins]

On Sunday, 2 August 2015 01:24:50 WET John Layt wrote:
> It would require a lot of shuffling code around, as a lot of code is
> in the d_ptr, it would horribly complicate things and there's the
> potential for interesting corner cases, like say adding enough years
> to a date to push it from one implementation to another... Is the
> complexity worth it?

It would also require a bunch of ifdefs because of 32 bit platforms.

If nobody is interested in implementing Robert's idea then I'm available to 
implement "use a nullptr to indicate shared null".



Regards,
-- 
Sérgio Martins | sergio.mart...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QLocale changed?

[David Faure]

This:

QCOMPARE(QLocale::c().toString(1234.0, 'f', 0), QString("1,234"));

was the behavior until Qt 5.5

With Qt 5.6, this happens:

   Actual   (QLocale::c().toString(1234.0, 'f', 0)): "1234"
   Expected (QString("1,234")) : "1,234"

Is this an expected change?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QLocale changed?

[Knoll Lars]

Its a behavioural change, after we got quite a few bug reports about this 
behaviour (being inconsistent with what people expect). See change 
3695285fde904935fc2e88010dac171144e8677a and the bug reports mentioned in there.

Cheers,
Lars




On 26/11/15 09:39, "Development on behalf of David Faure" 
 wrote:

>This:
>
>QCOMPARE(QLocale::c().toString(1234.0, 'f', 0), QString("1,234"));
>
>was the behavior until Qt 5.5
>
>With Qt 5.6, this happens:
>
>   Actual   (QLocale::c().toString(1234.0, 'f', 0)): "1234"
>   Expected (QString("1,234")) : "1,234"
>
>Is this an expected change?
>
>-- 
>David Faure, fa...@kde.org, http://www.davidfaure.fr
>Working on KDE Frameworks 5
>
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules.

[Koehne Kai]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Of Marc Mutz
> Sent: Thursday, November 26, 2015 9:53 AM
> To: development@qt-project.org
> Subject: Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules.
> 
> On Wednesday 25 November 2015 20:32:50 Thiago Macieira wrote:
> > On Wednesday 25 November 2015 18:27:11 Aleix Pol wrote:
> > > > Anyway, if this is a compiler bug, the conditions for triggering
> > > > it may not be evident.
> > >
> > > Does the fact that it's a compiler bug change the fact that it
> > > should be changed on the Qt side of things?
> > >
> > > If we have this compiler on the CI, Qt users will have it as well.
> >
> > No, it does not change the fact that we need to either work around or
> > remove the change that triggered it. Qt needs to compile with MSVC 2015.
> >
> > One way to do that is to disable noexcept for MSVC2015. Another is to
> > remove the use of .
> 
> We cannot remove the  use, because we cannot replace it with the
> noexcept operator we used before, because that already failed. We cannot
> remove noexcept in general, because it's now part of the API. We can, however,
> remove it for just MSVC.
> 
> > If the change is to remove noexcept, I'd like to know if Update 1
> > fixes the issue. If it doesn't, it would be a good idea to dissect a
> > testcase and submit to Microsoft. It would be the fourth one for
> > Update 1 that we found just by compiling Qt with all the C++11 features
> enabled...
> 
> Here's a test case for what I think might be the problem:
> 
>https://codereview.qt-project.org/141999

The test in this and the following patch set compile fine for me with MSVC 2015 
(32 bit),
while qtenginio fails. So it's not actually testing the problem.

Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules.

[Marc Mutz]

On Thursday 26 November 2015 10:10:50 Koehne Kai wrote:
> > -Original Message-
> > From: Development [mailto:development-boun...@qt-project.org] On Behalf
> > Of Marc Mutz
> > Sent: Thursday, November 26, 2015 9:53 AM
> > To: development@qt-project.org
> > Subject: Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules.
> > 
> > On Wednesday 25 November 2015 20:32:50 Thiago Macieira wrote:
> > > On Wednesday 25 November 2015 18:27:11 Aleix Pol wrote:
> > > > > Anyway, if this is a compiler bug, the conditions for triggering
> > > > > it may not be evident.
> > > > 
> > > > Does the fact that it's a compiler bug change the fact that it
> > > > should be changed on the Qt side of things?
> > > > 
> > > > If we have this compiler on the CI, Qt users will have it as well.
> > > 
> > > No, it does not change the fact that we need to either work around or
> > > remove the change that triggered it. Qt needs to compile with MSVC
> > > 2015.
> > > 
> > > One way to do that is to disable noexcept for MSVC2015. Another is to
> > > remove the use of .
> > 
> > We cannot remove the  use, because we cannot replace it with
> > the noexcept operator we used before, because that already failed. We
> > cannot remove noexcept in general, because it's now part of the API. We
> > can, however, remove it for just MSVC.
> > 
> > > If the change is to remove noexcept, I'd like to know if Update 1
> > > fixes the issue. If it doesn't, it would be a good idea to dissect a
> > > testcase and submit to Microsoft. It would be the fourth one for
> > > Update 1 that we found just by compiling Qt with all the C++11 features
> > 
> > enabled...
> > 
> > Here's a test case for what I think might be the problem:
> >https://codereview.qt-project.org/141999
> 
> The test in this and the following patch set compile fine for me with MSVC
> 2015 (32 bit), while qtenginio fails. So it's not actually testing the
> problem.

Then can someone please paste the code in question, because the error message 
didn't seem to include a location in enginio...

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules.

[Koehne Kai]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf
> Of Marc Mutz
> Sent: Thursday, November 26, 2015 12:00 PM
> To: development@qt-project.org
> Subject: Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules.
> 
> On Thursday 26 November 2015 10:10:50 Koehne Kai wrote:
> > > -Original Message-
> > > From: Development [mailto:development-boun...@qt-project.org] On
> > > Behalf Of Marc Mutz
> > > Sent: Thursday, November 26, 2015 9:53 AM
> > > To: development@qt-project.org
> > > Subject: Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules.
> > >
> > > On Wednesday 25 November 2015 20:32:50 Thiago Macieira wrote:
> > > > On Wednesday 25 November 2015 18:27:11 Aleix Pol wrote:
> > > > > > Anyway, if this is a compiler bug, the conditions for
> > > > > > triggering it may not be evident.
> > > > >
> > > > > Does the fact that it's a compiler bug change the fact that it
> > > > > should be changed on the Qt side of things?
> > > > >
> > > > > If we have this compiler on the CI, Qt users will have it as well.
> > > >
> > > > No, it does not change the fact that we need to either work around
> > > > or remove the change that triggered it. Qt needs to compile with
> > > > MSVC 2015.
> > > >
> > > > One way to do that is to disable noexcept for MSVC2015. Another is
> > > > to remove the use of .
> > >
> > > We cannot remove the  use, because we cannot replace it
> > > with the noexcept operator we used before, because that already
> > > failed. We cannot remove noexcept in general, because it's now part
> > > of the API. We can, however, remove it for just MSVC.
> > >
> > > > If the change is to remove noexcept, I'd like to know if Update 1
> > > > fixes the issue. If it doesn't, it would be a good idea to dissect
> > > > a testcase and submit to Microsoft. It would be the fourth one for
> > > > Update 1 that we found just by compiling Qt with all the C++11
> > > > features
> > >
> > > enabled...
> > >
> > > Here's a test case for what I think might be the problem:
> > >https://codereview.qt-project.org/141999
> >
> > The test in this and the following patch set compile fine for me with
> > MSVC
> > 2015 (32 bit), while qtenginio fails. So it's not actually testing the
> > problem.
> 
> Then can someone please paste the code in question, because the error
> message didn't seem to include a location in enginio...

I created a bug report with a stripped down example:

https://bugreports.qt.io/browse/QTBUG-49658


Cheers

Kai 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QFutureInterface

[Bauer, Christian]

Hello,

There was a discussion about the "internal" class QFutureInterface a few months 
ago on this list [1] about making QFuture/QFutureInterface more like 
std::future/std::promise in C++11.
It seems this is not going to happen before Qt 6.

We have a use case for a promise though and the current QFutureInterface is not 
sufficient. A custom wrapper for the QFutureInterface solves this problem for 
now, but requires a patch of Qt.

I am wondering if you are willing to incorporate this patch into the official 
Qt release. It's about adding a getter to QFutureInterfaceBase for the d 
pointer QWaitCondition. Such a getter already exists inside the 
QFutureInterfaceBase for the d pointer QMutex.

Thanks
 Christian


[1] http://lists.qt-project.org/pipermail/development/2015-July/022586.html
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QFutureInterface

[Marc Mutz]

Hi Christian,

On Thursday 26 November 2015 11:50:10 Bauer, Christian wrote:
> Hello,
> 
> There was a discussion about the "internal" class QFutureInterface a few
> months ago on this list [1] about making QFuture/QFutureInterface more
> like std::future/std::promise in C++11. It seems this is not going to
> happen before Qt 6.
> 
> We have a use case for a promise though and the current QFutureInterface is
> not sufficient. A custom wrapper for the QFutureInterface solves this
> problem for now, but requires a patch of Qt.
> 
> I am wondering if you are willing to incorporate this patch into the
> official Qt release. It's about adding a getter to QFutureInterfaceBase
> for the d pointer QWaitCondition. Such a getter already exists inside the
> QFutureInterfaceBase for the d pointer QMutex.

You should be able to develop a QPromise/QPackagedTask with the current 
QFutureInterface already. At least as long as it's attached to some 
QThreadPool. What, exactly, are you trying to do that requires a patch to QFI?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [Announce] Qt Creator 3.6 RC1 released

[List for announcements regarding Qt releases and development]

We are happy to announce the release of Qt Creator 3.6 RC1:

http://blog.qt.io/blog/2015/11/26/qt-creator-3-6-rc1-released/

Br,
-- 
Eike Ziller, Senior Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Announce mailing list
annou...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/announce
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development