On Sun, Nov 24, 2019 at 09:48:46PM -0800, Thiago Macieira wrote:
> 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
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 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,
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
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
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
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 to Qt itself).
>
> Wrapping int() around requires more manual work.
I un
On Sat, Nov 23, 2019 at 12:48:12PM +0100, Thiago Macieira wrote:
> On Saturday, 23 November 2019 09:47:23 CET André Pönitz wrote:
> > So let's make this a real proposal: Should we have
> >
> >qsizetype QContainer::size()
> >int QContainer::count() const
>
> So you propose changing code li
On Saturday, 23 November 2019 09:47:23 CET André Pönitz wrote:
> So let's make this a real proposal: Should we have
>
>qsizetype QContainer::size()
>int QContainer::count() const
So you propose changing code like
int n = vec.size();
to
int n = vec.count();
while we could
Il 23/11/19 09:47, André Pönitz ha scritto:
So let's make this a real proposal: Should we have
qsizetype QContainer::size()
int QContainer::count() const
?
It's an idea, but overly confusing and will make our API a mess.
(Also, concretely, what about count(T), indexOf(T), capacity(),
On Fri, Nov 22, 2019 at 08:01:30PM +0100, Giuseppe D'Angelo via Development
wrote:
> Il 22/11/19 18:49, Thiago Macieira ha scritto:
> > We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment
> > where you can't use qsizetype in Qt 6. We'll deal with conflicts.
>
> Sorry, what d
On Friday, 22 November 2019 20:01:30 CET Giuseppe D'Angelo via Development
wrote:
> Il 22/11/19 18:49, Thiago Macieira ha scritto:
> > We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment
> > where you can't use qsizetype in Qt 6. We'll deal with conflicts.
>
> Sorry, what do
Il 22/11/19 18:49, Thiago Macieira ha scritto:
We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment
where you can't use qsizetype in Qt 6. We'll deal with conflicts.
Sorry, what do you mean by "conflicts"? I mean that there's countless
code today that uses "int s = foo.siz
On Friday, 22 November 2019 18:04:22 CET Giuseppe D'Angelo via Development
wrote:
> So the mandatory question is: how many warnings is this going to cause,
> and how to port code whilst maintaining Qt 5 compatibility?
We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment
wher
Il 22/11/19 18:00, Thiago Macieira ha scritto:
We didn't discuss because it's a given that we will do that. :-)
So the mandatory question is: how many warnings is this going to cause,
and how to port code whilst maintaining Qt 5 compatibility?
Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@
On Friday, 22 November 2019 16:43:16 CET Giuseppe D'Angelo via Development
wrote:
> Spawning a subthread since we didn't discuss this at all...
>
> Are the plans still to make the containers' size_type qsizetype?
We didn't discuss because it's a given that we will do that. :-)
Lars's patchset a
Il 21/11/19 19:48, Giuseppe D'Angelo via Development ha scritto:
Written here:
https://wiki.qt.io/Qt_Contributor_Summit_2019_-_QtCore
Spawning a subthread since we didn't discuss this at all...
Are the plans still to make the containers' size_type qsizetype?
Thanks,
--
Giuseppe D'Angelo |
On Thursday, 21 November 2019 19:48:03 CET Giuseppe D'Angelo via Development
wrote:
> Written here:
> > https://wiki.qt.io/Qt_Contributor_Summit_2019_-_QtCore
>
> Thanks,
Thanks Peppe
* What does Qt assume on locale on UNIX systems?
** What happens if you haven't set anything?
*** Thiago: assume
Written here:
https://wiki.qt.io/Qt_Contributor_Summit_2019_-_QtCore
Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smi
21 matches
Mail list logo
