On Sunday, 24 November 2019 09:25:37 PST Olivier Goffart wrote:
> So moc stays much faster than actually compiling, but it has been reported
> that moc does not play nice with ccache or distributed compile farm.
There's no reason why moc can't be ccache'd.
As for a compile farm, the big problem i
On Sunday, 24 November 2019 12:18:07 PST Arnaud Clère wrote:
> - Thiago recognized that this kind of API would be valuable to Qt users but
> at least the naming is problematic, so he should provide feedback before it
> can be pushed to and reviewed on gerrit
My point is that I can see the value in
On Sunday, 24 November 2019 00:50:14 PST André Pönitz wrote:
> Regarding the risk of "introduce subtle bugs by truncating sizes": That risk
> _is_ there in general for some of the proposed porting strategies, but not
> for the case of using a 32bit count(): We can assume that an existing
> applicat
On 24.11.19 21:53, Mathias Hasselmann wrote:
OMG, are you really sure about these massive changes?
Not 100% sure, no.
What specific changes are you worried about?
In this case, I believe the changes should lead to only small behavior changes
which are in fact fixes.
But this is of course up t
OMG, are you really sure about these massive changes?
I am pretty sure that this will introduce countless hard to catch
porting issues. After all there are no compiler warnings for this, only
subtile behavior changes and I doubt that all the Qt based projects out
there have sufficient test cov
Hi all,
Thank you for the discussions at QtCS19!
The notes regarding the session on serialization are on the wiki:
https://wiki.qt.io/Rethinking_serialization_for_Qt6
To summarize:
- Although it seemed strange to many people, it is possible to provide an
API so that a single T::zap() method can r
On 24.11.19 12:36, Lars Knoll wrote:
Hi Olivier,
Thanks for looking through this and coming up with a proposal. I like the
direction.
On 22 Nov 2019, at 14:32, Olivier Goffart wrote:
Hi,
This is a follow-up on what was discussed in the (second part of the) QtCore
session in the QtCS.
Lars
On 24.11.19 12:24, Giuseppe D'Angelo via Development wrote:
Il 21/11/19 17:38, Joerg Bornemann ha scritto:
It works and produces seemingly the correct output, able to consume
modern C++ constructs.
But it's sloow. Running on Qt Creator takes 1 min with the old
parser, and 50 min with the new
On Sun, Nov 24, 2019 at 12:31:32PM +0100, Konrad Rosenbaum wrote:
> I'd rather have the compiler tell me that I need to change my code than hide
> it from me. Warnings are there for a good reason.
["Some"...]
> The only way to do this with this proposal is to make count() deprecated from
> the st
Hi Olivier,
Thanks for looking through this and coming up with a proposal. I like the
direction.
> On 22 Nov 2019, at 14:32, Olivier Goffart wrote:
>
> Hi,
>
> This is a follow-up on what was discussed in the (second part of the) QtCore
> session in the QtCS.
> Lars and others have been ment
Hi,
On 11/23/19 9:47 AM, André Pönitz wrote:
qsizetype QContainer::size()
int QContainer::count() const
Please no! This will forever flood the interest mail list with questions
about what the difference between the two methods is. It will also
introduce a lot of subtle little misbeh
Il 21/11/19 17:38, Joerg Bornemann ha scritto:
It works and produces seemingly the correct output, able to consume
modern C++ constructs.
But it's sloow. Running on Qt Creator takes 1 min with the old
parser, and 50 min with the new one.
Related question: does also a clang-based moc suffer
On Sun, Nov 24, 2019 at 11:30:29AM +0100, Giuseppe D'Angelo via Development
wrote:
> Il 24/11/19 10:44, Uwe Rathmann ha scritto:
> > I fully agree with André - having 2 different APIs makes a lot of sense
> > to me. But instead of using count/size I would use something like
> > countU/sizeU. like
Il 24/11/19 10:44, Uwe Rathmann ha scritto:
I fully agree with André - having 2 different APIs makes a lot of sense
to me. But instead of using count/size I would use something like
countU/sizeU. like you have QPen::widthF and QPen::width.
I disagree: it makes the API confusing. The F there sta
Am 22.11.19 um 21:25 schrieb Kai Pastor, DG0YT:
Am 22.11.19 um 17:03 schrieb Kai Köhne:
Keep in mind that you need this context available both at runtime and
at lupdate time. That is, the only setup how this IMO would reliably work
is if we make the context a part of the tr() call - effectively
On 11/23/19 11:26 PM, Thiago Macieira wrote:
Wrapping int() around requires more manual work.
I understand, but I think this is the type of change that will eventually
become a problem down the road. We think it can help with porting, but it may
later introduce subtle bugs by truncating sizes.
On Sat, Nov 23, 2019 at 11:26:02PM +0100, Thiago Macieira wrote:
> On Saturday, 23 November 2019 13:55:52 CET André Pönitz wrote:
> > Also, replacing size() by count() would be easy to do in e.g. Creator
> > (effectively a single global renaming of size() to count() and discarding
> > the changes t
17 matches
Mail list logo
