On Saturday, 11 March 2023 00:48:10 PST A. Pönitz wrote:
> Unfortunately for myself (and I am ready to take some blame for this
> ignorance) there was this parallel, and for me on first sight unrelated,
> development of the Q*View zoo, that started to set sizeof(qsizeype) ==
> sizeof(std::size_t)
On Thu, Mar 09, 2023 at 02:08:48PM +0100, Hasselmann Mathias via Development
wrote:
> My take on qsizetype: Just revert this failed experiment.
>
> It's a huge annoyance for little to no benefit.
Correct.
> I'll never understand how this very broken and incomplete experiment could
> make it
On Thursday, 9 March 2023 05:08:48 PST Hasselmann Mathias via Development
wrote:
> My take on qsizetype: Just revert this failed experiment. It's a huge
> annoyance for little to no benefit. I'll never understand how this very
> broken and incomplete experiment could make it into Qt's main branch
My take on qsizetype: Just revert this failed experiment. It's a huge
annoyance for little to no benefit. I'll never understand how this very
broken and incomplete experiment could make it into Qt's main branch at all.
Am 13.09.2022 um 15:12 schrieb Volker Hilsheimer:
On 12 Sep 2022, at
On 9/3/23 10:14, Marc Mutz via Development wrote:
On 08.03.23 15:30, Ahmad Samir wrote:
So, named casts (static_cast) are better in such cases, as searching for
them in source code is much easier than searching for:
- int(foo)
- (int)foo
- (int)(foo)
In which situation would you want to
On 08.03.23 15:30, Ahmad Samir wrote:
> So, named casts (static_cast) are better in such cases, as searching for
> them in source code is much easier than searching for:
> - int(foo)
> - (int)foo
> - (int)(foo)
In which situation would you want to search for all casts in a piece of source
code?
On 1/9/22 12:15, Marc Mutz wrote:
This should be non-issue for function parameters, because widening isn't
an error. The value is less pronounced for return values, because
widening those may cause narrowing in user code, but the hope is that
once we've progressed somewhat, we can enlist
On Tue, Sep 13, 2022 at 01:12:57PM +, Volker Hilsheimer wrote:
> > On Wed, Sep 07, 2022 at 06:38:30PM +0200, A. Pönitz wrote:
> >> [...] What would have been wrong with starting with
> >>
> >> #ifdef I_AM_WORKING_ON_IT using qsizetyp_ = qsizetype; #else using
> >> qsizetyp_ = int; #endif
> >>
> On 12 Sep 2022, at 20:04, A. Pönitz wrote:
>
> On Wed, Sep 07, 2022 at 06:38:30PM +0200, A. Pönitz wrote:
>> On Mon, Sep 05, 2022 at 05:15:45PM +, Marc Mutz wrote:
>>> [...]
>>> We have the tools (QT_REMOVED_SINCE + Ivan's work on
>>> -disable-deprecated-until) to have a
On Wed, Sep 07, 2022 at 06:38:30PM +0200, A. Pönitz wrote:
> On Mon, Sep 05, 2022 at 05:15:45PM +, Marc Mutz wrote:
> > [...]
> >We have the tools (QT_REMOVED_SINCE + Ivan's work on
> >-disable-deprecated-until) to have a user-configurable, rolling BC window
> >now We should use
On Thursday, 8 September 2022 02:23:39 PDT Edward Welbourne wrote:
> The reason we plan for Qt 7 is that it's the next time we can make
> certain kinds of backwards-incompatible changes. When we decide that
> such a change is needed, we plan for it, because we can't do it yet, or
> indeed any
Nicolas Fella wrote:
>> The fact that KDE does not use Qt6 yet has rather little to do with
>> the quality of Qt6.
Kevin Kofler (8 September 2022 01:37) replied:
> Where have I claimed that it does? I sense a strawman…
>
> My point is that it takes time for KDE and other downstreams to adopt
> a
Nicolas Fella wrote:
> The fact that KDE does not use Qt6 yet has rather little to do with the
> quality of Qt6.
Where have I claimed that it does? I sense a strawman…
My point is that it takes time for KDE and other downstreams to adopt a new
major release of Qt, no matter the reason why it
Am 07.09.22 um 08:45 schrieb Kevin Kofler via Development:
Alex Blasche wrote:
2.) An alternative might be to make this change in one go for Qt 7. We
would keep Qt 6.x on the status quo but start adding compatible
replacement APi with an absolute change at 7.0 (ifdefs or typedefs come to
mind).
Ilya Fedin wrote:
> I believe the fact KDE is not ported to Qt 6 yet is more question of
> bureaucracy coordination of a lot of people in different KDE projects.
> That is, deciding that they want to port to Qt 6 takes time, then every
> project maintainer should do the port and it seems they want
On Tuesday, 6 September 2022 23:45:45 PDT Kevin Kofler via Development wrote:
> It scares me that a Qt 7 is already being planned or discussed at all,
We had "### Qt 7" remarks in Qt 6.0.0.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud
On Mon, Sep 05, 2022 at 05:15:45PM +, Marc Mutz wrote:
> [...]
>We have the tools (QT_REMOVED_SINCE + Ivan's work on
>-disable-deprecated-until) to have a user-configurable, rolling BC window
>now We should use these tools to avoid accumulating too much technical
>[...]
>
> On 7 Sep 2022, at 08:36, Alex Blasche wrote:
>
> Hi Volker,
>
>>
>> From: Development on behalf of Volker
>> Hilsheimer
>
>> I agree that it would be great if users of Qt could flip on aggressive
>> compile options to get warnings about
On Wed, 07 Sep 2022 08:45:45 +0200
Kevin Kofler via Development wrote:
> It scares me that a Qt 7 is already being planned or discussed at
> all, considering that your major consumers such as KDE Plasma are not
> even ported to Qt 6 yet! (Note that I am talking about *consumers*
> here, not only
> On 7 Sep 2022, at 09:00, Andreas Aardal Hanssen wrote:
>
> On Wed, Sep 7, 2022, at 08:45, Kevin Kofler via Development wrote:
>> Alex Blasche wrote:
>>> 2.) An alternative might be to make this change in one go for Qt 7. We
>>> would keep Qt 6.x on the status quo but start adding compatible
On Wed, Sep 7, 2022, at 08:45, Kevin Kofler via Development wrote:
> Alex Blasche wrote:
> > 2.) An alternative might be to make this change in one go for Qt 7. We
> > would keep Qt 6.x on the status quo but start adding compatible
> > replacement APi with an absolute change at 7.0 (ifdefs or
Alex Blasche wrote:
> 2.) An alternative might be to make this change in one go for Qt 7. We
> would keep Qt 6.x on the status quo but start adding compatible
> replacement APi with an absolute change at 7.0 (ifdefs or typedefs come to
> mind). Users would only be burdened one time (though it
Hi Volker,
>
>From: Development on behalf of Volker
>Hilsheimer
>I agree that it would be great if users of Qt could flip on aggressive compile
>options to get warnings about narrowing-conversions.
>But again, is that worth it? And is that more
> On 5 Sep 2022, at 19:15, Marc Mutz wrote:
>
> Hi,
>
> Experience shows that we'll have many, many, many things to consider come Qt
> 7. And as Qt 6 has shown, such trivialities will be left by the wayside. So,
> playing the devil's advocate here: if this work is too much for Qt 6.x, what
>
Volker Hilsheimer (5 September 2022 17:31) wrote:
>> We have virtual functions that take int and could potentially be fed
>> by the return value of container.size() (or generally need to be able
>> to handle values >2G), so should take a qsizetype (say,
>> QAbstractItemModel::insertRows,
Hi,
Experience shows that we'll have many, many, many things to consider come Qt 7.
And as Qt 6 has shown, such trivialities will be left by the wayside. So,
playing the devil's advocate here: if this work is too much for Qt 6.x, what
makes us think we'll get it done in the frenzy leading up
> On 5 Sep 2022, at 14:46, Alex Blasche wrote:
>> -Original Message-
>> From: Development On Behalf Of
>> Marc Mutz
[…]
>> I just want to raise awareness of the issue, which, really, is just an
>> incomplete
>> port of the Qt containers to qsizetype in 6.0.
>>
>> Over the last
> -Original Message-
> From: Development On Behalf Of
> Marc Mutz
I am taking the hot potato and spin this futher.
> You may have seen the qsizetype patches we've been pushing over the last
> months. This is to give my perspective on the issue and why I think it's
> needed:
>
> First
Hi,
You may have seen the qsizetype patches we've been pushing over the last
months. This is to give my perspective on the issue and why I think it's
needed:
First off, while I made QStringView qsizetype'd, because it was designed
to take input from STL containers[1], I was not involved in
> On 27 Aug 2020, at 08:04, Giuseppe D'Angelo via Development
> wrote:
>
> Hi,
>
> Il 27/08/20 02:46, Thiago Macieira ha scritto:
>> A QListView of 2 billion lines with where each line is a QString one
>> to 7 characters in length would be 2G * (24 + 32) = 96 GB of memory use.
>> QListWidget's
On 25/08/2020 15.15, André Pönitz wrote:
On Mon, Aug 24, 2020 at 09:46:43AM +0200, Mathias Hasselmann wrote:
C++ also has a solution for that problem: [1]
https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
AAA is a non-solution from the ivory tower.
Hi,
Il 27/08/20 16:47, Thiago Macieira ha scritto:
So, can someone take a look at what it would take to make the models use 64-
bit and come up with a proper guide for how to maintain code that compiles and
works on both Qt5 and Qt6? The latter is very important: if you can't easily
maintain
On Thursday, 27 August 2020 00:52:10 PDT Lars Knoll wrote:
> > On 27 Aug 2020, at 09:12, Philippe wrote:
> >>> * QAbstractItemModel
> >>> * QModelIndex
> If I were do design these from scratch, I would certainly use qsizetype
> here, maybe even a qint64 (because one can handle those large data
Il 25/08/20 07:49, Thiago Macieira ha scritto:
>> But how about models? This is an honest question. Does it make sense
>> for tables and lists that big? Note that an item*view* has a purpose
>> of being viewed, so how does one display such a huge list, tree or
>> table?
Giuseppe D'Angelo (25
On 27 Aug 2020, at 10:45, Lars Knoll
mailto:lars.kn...@qt.io>> wrote:
On 27 Aug 2020, at 08:32, Lars Knoll
mailto:lars.kn...@qt.io>> wrote:
On 27 Aug 2020, at 08:04, Giuseppe D'Angelo via Development
mailto:development@qt-project.org>> wrote:
Hi,
Il 27/08/20 02:46, Thiago Macieira ha
On 27 Aug 2020, at 08:32, Lars Knoll
mailto:lars.kn...@qt.io>> wrote:
On 27 Aug 2020, at 08:04, Giuseppe D'Angelo via Development
mailto:development@qt-project.org>> wrote:
Hi,
Il 27/08/20 02:46, Thiago Macieira ha scritto:
A QListView of 2 billion lines with where each line is a QString one
> On 27 Aug 2020, at 09:12, Philippe wrote:
>
> On Wed, 26 Aug 2020 06:36:27 +
> Lars Knoll wrote:
>
>>> * QAbstractItemModel
>>> * QModelIndex
>>
>> I dont think we should port these to use qsizetype.
>
> If you mean, the effort would be too big, or there is lack of resources
> to do
On Wed, 26 Aug 2020 06:36:27 +
Lars Knoll wrote:
> > * QAbstractItemModel
> > * QModelIndex
>
> I dont think we should port these to use qsizetype.
If you mean, the effort would be too big, or there is lack of resources
to do it, or too many API breaks for Qt 5 to 6, then I can agree.
> On 27 Aug 2020, at 08:04, Giuseppe D'Angelo via Development
> wrote:
>
> Hi,
>
> Il 27/08/20 02:46, Thiago Macieira ha scritto:
>> A QListView of 2 billion lines with where each line is a QString one to 7
>> characters in length would be 2G * (24 + 32) = 96 GB of memory use.
>> QListWidget's
Hi,
Il 27/08/20 02:46, Thiago Macieira ha scritto:
A QListView of 2 billion lines with where each line is a QString one to 7
characters in length would be 2G * (24 + 32) = 96 GB of memory use.
QListWidget's overhead is much worse.
This isn't accurate; QListView (with the default delegate)
On Wednesday, 26 August 2020 17:23:16 PDT Lisandro Damián Nicanor Pérez Meyer
wrote:
> > Disagree here. There is good reason many in my industry (Electronic
> > design automation) use the Scintilla editor widget inside Qt apps.
> > Specifically to handle extremely large, in both line count and
Hi!
El mié., 26 ago. 2020 16:59, Scott Bloom escribió:
> From: Development On Behalf Of Ville
> Voutilainen
> Sent: Wednesday, August 26, 2020 12:08 AM
> To: Lars Knoll
> Cc: Qt development mailing list
> Subject: Re: [Development] qsizetype and classes working with Q
From: Development On Behalf Of Ville
Voutilainen
Sent: Wednesday, August 26, 2020 12:08 AM
To: Lars Knoll
Cc: Qt development mailing list
Subject: Re: [Development] qsizetype and classes working with QStrings or QList
On Wed, 26 Aug 2020 at 09:39, Lars Knoll wrote:
> >
Il 25/08/20 21:05, André Pönitz ha scritto:
why I wanted a configure time switch to choose the size of qsizetype).
This doesn't really help if Qt comes with your distribution or even with
the Qt installers.
What I meant is that it would be a porting aid towards Qt 6, rather than
a switch to
this would be
not a replacement of QDocument.
-Original Message-
From: Development On Behalf Of Lars Knoll
Sent: Wednesday, August 26, 2020 9:23 AM
To: Ville Voutilainen
Cc: Qt development mailing list
Subject: Re: [Development] qsizetype and classes working with QStrings or QList
> On 26 Aug 2020, at 09:07, Ville Voutilainen
> wrote:
>
> On Wed, 26 Aug 2020 at 09:39, Lars Knoll wrote:
>>> QtGui:
>>> * QTextCursor
>>> * QTextDocument (find offset, character{At,Count})
>>> * QTextLayout
>>> * QValidator and subclasses (validate offset)
>>
>> These here are
On Wed, 26 Aug 2020 at 09:39, Lars Knoll wrote:
> > QtGui:
> > * QTextCursor
> > * QTextDocument (find offset, character{At,Count})
> > * QTextLayout
> > * QValidator and subclasses (validate offset)
>
> These here are questionable. Editing a text file with more than 2G
> characters? Sounds
Going back to the original question here:
> On 23 Aug 2020, at 16:06, Marcel Krems wrote:
>
> Hi,
>
> since QString, QList, etc. are using qsizetype for indexing- and
> size-operations.
> What is the plan with classes working with aforementioned container classes
> which are still using int
t-project.org] On Behalf Of
André Pönitz
Sent: Tuesday, August 25, 2020 12:15
To: Mathias Hasselmann
Cc: development@qt-project.org
Subject: Re: [Development] qsizetype and classes working with QStrings or QList
On Mon, Aug 24, 2020 at 09:46:43AM +0200, Mathias Hasselmann wrote:
>C++ als
On Mon, Aug 24, 2020 at 09:46:43AM +0200, Mathias Hasselmann wrote:
>C++ also has a solution for that problem: [1]
>
> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
AAA is a non-solution from the ivory tower.
It's a pain for human reviewers and tools
On Mon, Aug 24, 2020 at 09:26:54AM +0200, Giuseppe D'Angelo via Development
wrote:
> On 23/08/2020 16:06, Marcel Krems wrote:
> > If they keep using int there could be a lot of warnings like this one:
> > warning: implicit conversion loses integer precision: 'qsizetype' (aka
> > 'long long') to
On 25/08/2020 02.22, Mathias Hasselmann wrote:
I'd really enjoy implementing list models without having
to litter static casts all over the place. Well, but seems that chance
got missed once again with qsizetype still being signed.
That's intentional. There are problems with unsigned index
On 25/08/2020 05.58, Giuseppe D'Angelo via Development wrote:
Il 25/08/20 07:49, Thiago Macieira ha scritto:
But how about models? This is an honest question. Does it make sense for
tables and lists that big? Note that an item*view* has a purpose of
being viewed, so how does one display such
On 25/08/2020 01.24, Philippe wrote:
But then there would be the need to make QAbstractSlider be able to
handle 64 bit quantities too.
Well, since you mentioned it:
https://github.com/Kitware/qtextensions/blob/master/widgets/qtDoubleSlider.h
No, that isn't a two-headed slider, it's a slider
On Monday, 24 August 2020 23:11:17 PDT Philippe wrote:
> > This is an honest question. Does it make sense for
> > tables and lists that big? Note that an item *view* has a purpose of being
> > viewed, so how does one display such a huge list, tree or table?
>
> I have a concrete case: in the
Il 25/08/20 07:49, Thiago Macieira ha scritto:
But how about models? This is an honest question. Does it make sense for
tables and lists that big? Note that an item*view* has a purpose of being
viewed, so how does one display such a huge list, tree or table?
Just another thought -- models
Well, yes, when displaying huge databases, for example. This use-case pops up
quite often from my experience. It is rare to contain more than 2^31 elements,
yes, but one has to be aware of that case and support it somehow which leads to
overcompicated code that does «paging», for example. And
Am 25.08.2020 um 01:09 schrieb Thiago Macieira:
On Monday, 24 August 2020 15:10:24 PDT Иван Комиссаров wrote:
It would be nice if QAbstractItemModel will support qsizetype instead of
int, but I do not see how this is possible considering the fact that
rowCount/columnCount return int. I
> This is an honest question. Does it make sense for
> tables and lists that big? Note that an item *view* has a purpose of being
> viewed, so how does one display such a huge list, tree or table?
I have a concrete case: in the audio domain, it's common to have audio
files with more than 2
On Monday, 24 August 2020 22:24:52 PDT Philippe wrote:
> > Do we need models with more than 2 billion rows or columns?
>
> More than we need in-memory containers with more than 2 billion entries,
> no?
More? We see a lot of data processing bumping up to gigabyte levels.
Containers with more
> Do we need models with more than 2 billion rows or columns?
More than we need in-memory containers with more than 2 billion entries,
no?
For instance, one could wish to display in a list view, the contents of
a file with more than 2 billions "entries".
But then there would be the need to make
On Monday, 24 August 2020 15:10:24 PDT Иван Комиссаров wrote:
> It would be nice if QAbstractItemModel will support qsizetype instead of
> int, but I do not see how this is possible considering the fact that
> rowCount/columnCount return int. I suppose, it is not very hard to patch
> QModelIndex,
It would be nice if QAbstractItemModel will support qsizetype instead of int,
but I do not see how this is possible considering the fact that
rowCount/columnCount return int. I suppose, it is not very hard to patch
QModelIndex, but what to do with virtual functions? The user code will break.
https://bugreports.qt.io/browse/QTBUG-86224
On 24.08.2020 09:26, Giuseppe D'Angelo via Development wrote:
On 23/08/2020 16:06, Marcel Krems wrote:
If they keep using int there could be a lot of warnings like this one:
warning: implicit conversion loses integer precision: 'qsizetype' (aka
On 24/08/2020 11:17, Mathias Hasselmann wrote:
Do you have examples showing verifiable evidence, or do you share a feeling?
There has been quite a flurry of patches into Qt fixing the generated
warnings (shortening 64-to-32, using "%d" in printf, and the like). I
don't have a way to list
On Mon, 24 Aug 2020 at 15:37, Christian Kandeler
wrote:
> > I don't have verifiable evidence examples, but the gist of it is this:
> >
> > ConcreteType x = foo(); // this detects API breaks right here, right now
> > ...
> > ...
> > ...
> > some_use_of(x);
> >
> > With AAA, this might become
> >
>
On Mon, 24 Aug 2020 14:45:19 +0300
Ville Voutilainen wrote:
> On Mon, 24 Aug 2020 at 12:17, Mathias Hasselmann
> wrote:
> > >> C++ also has a solution for that problem:
> > >> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
> > > That non-solution is terrible.
On Mon, 24 Aug 2020 at 12:17, Mathias Hasselmann
wrote:
> >> C++ also has a solution for that problem:
> >> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
> > That non-solution is terrible. The very reason for not using deduced
> > types is to detect API breaks
Am 24.08.2020 um 11:04 schrieb Ville Voutilainen:
On Mon, 24 Aug 2020 at 10:50, Mathias Hasselmann
wrote:
Am 24.08.2020 um 09:26 schrieb Giuseppe D'Angelo via Development:
On 23/08/2020 16:06, Marcel Krems wrote:
If they keep using int there could be a lot of warnings like this one:
On Mon, 24 Aug 2020 at 10:50, Mathias Hasselmann
wrote:
>
> Am 24.08.2020 um 09:26 schrieb Giuseppe D'Angelo via Development:
>
> On 23/08/2020 16:06, Marcel Krems wrote:
>
> If they keep using int there could be a lot of warnings like this one:
> warning: implicit conversion loses integer
Am 24.08.2020 um 09:26 schrieb Giuseppe D'Angelo via Development:
On 23/08/2020 16:06, Marcel Krems wrote:
If they keep using int there could be a lot of warnings like this one:
warning: implicit conversion loses integer precision: 'qsizetype' (aka
'long long') to 'int' [-Wshorten-64-to-32]
On 23/08/2020 16:06, Marcel Krems wrote:
If they keep using int there could be a lot of warnings like this one:
warning: implicit conversion loses integer precision: 'qsizetype' (aka
'long long') to 'int' [-Wshorten-64-to-32]
I'm afraid that these warnings will be all over the place anyhow.
Hi,
since QString, QList, etc. are using qsizetype for indexing- and
size-operations.
What is the plan with classes working with aforementioned container
classes which are still using int in their interfaces?
If they keep using int there could be a lot of warnings like this one:
warning:
73 matches
Mail list logo
