Re: [Development] qsizetype and classes working with QStrings or QList
> 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 overhead is much worse. > > This isn't accurate; QListView (with the default delegate) doesn't cache > data, and only fetches and shows what's visible in its viewport. So the > actual consumption is pretty much constant no matter how big is the > underlying model. Correct. But the argument for QTextDocument still holds. If you have such huge files, I believe you want to load them using some custom editing component that mmaps the file and only loads the relevant parts on the fly. QTextDocument allows for rich text editing and requires to hold the content in memory in a QString because of that. QTextDocument should be able to handle very large regular documents this without larger issues. Just as a comparison: All Harry Potter books together are around 1.1M words, ie. around 10M characters. Loading that (or even a 10 times larger document) into a QTextDocument should work without issues. But a 5G set of machine generated data? I would believe you want a special class handling that and loading data on the fly, so you have some memory left for the rest of your system. Having said that, I don’t mind changing our API to use qsizetype for QTextDocument, I just don’t believe you will find the class to be very snappy and usable with such large documents. The piece table itself should be able to handle it if you have enough RAM, but the default layout engine probably can’t (you could try using your own custom layout though). Cheers, Lars ___ To be clear, I am not expecting a QTextDocument as is to perform well under these loads (especially the 5gb files) in its normal usage form. However, i can see someone extending qtextdocument to handle large files using one of many strategies. Thanks Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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. It's a pain for human reviewers and tools operating on less then a full translation unit. (Almost) real-world example: for (auto i = foo.guess_stuff(); --i >= 0; ) do_something(i); Good? Bad? Bad, *but*... for (auto const i : indexRange(foo.guess_stuff()) | range::reverse) do_something(i) ...better! ;-) Also answers Scott's question. (I'll assume `do_something` is actually something complicated enough that std::for_each or the like wouldn't be preferred. Also note that exact spelling of the above will depend on where you are getting range utilities; in my case, I'm lucky if I can use C++14, so I have my own implementations.) BTW, AAA encourages duck typing, which may be a good or bad thing depending on your perspective. -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 for both, we just add to users' pain. It might be as simple as a typedef added to QAbstractItemModel. Finger in the wind: it's going to be painful. int-based APIs are used - in virtuals in QAbstractItemModel (rowCount(), but also things like moveRows() which take int as parameter, so changing it is a straight API break) - in Q(Persistent)ModelIndex - in convenience subclasses like QStandardItemModel (and of course in the convenience views) - in selection handling - in the views' convenience handlers (e.g. QAbstractItemView::rowsInserted) Long story short, I don't see this happening without also some configure-time switch for a "qaimsizetype" or somesuch. My 2 c, -- 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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 sets on > 32bit systems as well with on demand loading of the data). Good point. File sizes are qint64, so I agree any quantity that is tied to data, not to memory, should either use int or qint64. 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 for both, we just add to users' pain. It might be as simple as a typedef added to QAbstractItemModel. Like the q6sizetype typedef that was proposed and I never implemented. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 August 2020 11:58) replied: > Just another thought -- models may not necessarily used directly with > views but as data sources for other business logic parts of the > application (including but not necessarily limited to proxy models). > Given the underlying data sources are 64-bit capable, such models > should be as well. and, at a more brutal level: in the late '90s, I ported a Geographic Information System to cope with database files > 2GB in size (despite the fact that the underlying OSen didn't; I had to use a virtual file system), because we had customers whose datasets were big enough to need it. I consequently cannot believe, more than two decades later, that 2GB size limits on containers make sense. Even if we didn't have a use-case we could think of, some user out there almost certainly has, or shall within Qt6's life-time have, such use-cases. Coding to cope with them gracefully may, of course, require care: but we must support them. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 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) doesn't cache data, and only fetches and shows what's visible in its viewport. So the actual consumption is pretty much constant no matter how big is the underlying model. Correct. But the argument for QTextDocument still holds. If you have such huge files, I believe you want to load them using some custom editing component that mmaps the file and only loads the relevant parts on the fly. QTextDocument allows for rich text editing and requires to hold the content in memory in a QString because of that. QTextDocument should be able to handle very large regular documents this without larger issues. Just as a comparison: All Harry Potter books together are around 1.1M words, ie. around 10M characters. Loading that (or even a 10 times larger document) into a QTextDocument should work without issues. But a 5G set of machine generated data? I would believe you want a special class handling that and loading data on the fly, so you have some memory left for the rest of your system. Having said that, I don’t mind changing our API to use qsizetype for QTextDocument, I just don’t believe you will find the class to be very snappy and usable with such large documents. The piece table itself should be able to handle it if you have enough RAM, but the default layout engine probably can’t (you could try using your own custom layout though). I’ll give it a try and let’s see. There are very few to no virtual functions that would be affected, so changing the classes to use qsizetype might be worthwhile. Did a quick trial, and I don’t think it’s worth it. It’s quite a lot of work and will break user code in some places for very little gain. Little gain not because there aren’t use cases that need to handle very large documents, but because QTextEdit and QTextDocument are probably not the right classes to do so given that they load everything into memory at once. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 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) doesn't cache data, and only fetches and shows what's visible in its viewport. So the actual consumption is pretty much constant no matter how big is the underlying model. Correct. But the argument for QTextDocument still holds. If you have such huge files, I believe you want to load them using some custom editing component that mmaps the file and only loads the relevant parts on the fly. QTextDocument allows for rich text editing and requires to hold the content in memory in a QString because of that. QTextDocument should be able to handle very large regular documents this without larger issues. Just as a comparison: All Harry Potter books together are around 1.1M words, ie. around 10M characters. Loading that (or even a 10 times larger document) into a QTextDocument should work without issues. But a 5G set of machine generated data? I would believe you want a special class handling that and loading data on the fly, so you have some memory left for the rest of your system. Having said that, I don’t mind changing our API to use qsizetype for QTextDocument, I just don’t believe you will find the class to be very snappy and usable with such large documents. The piece table itself should be able to handle it if you have enough RAM, but the default layout engine probably can’t (you could try using your own custom layout though). I’ll give it a try and let’s see. There are very few to no virtual functions that would be affected, so changing the classes to use qsizetype might be worthwhile. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
> 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 it, or too many API breaks for Qt 5 to 6, then I can agree. > > But if you mean there is no usage need, I disagree. 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 sets on 32bit systems as well with on demand loading of the data). Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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. But if you mean there is no usage need, I disagree. Philippe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
> 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 overhead is much worse. > > This isn't accurate; QListView (with the default delegate) doesn't cache > data, and only fetches and shows what's visible in its viewport. So the > actual consumption is pretty much constant no matter how big is the > underlying model. Correct. But the argument for QTextDocument still holds. If you have such huge files, I believe you want to load them using some custom editing component that mmaps the file and only loads the relevant parts on the fly. QTextDocument allows for rich text editing and requires to hold the content in memory in a QString because of that. QTextDocument should be able to handle very large regular documents this without larger issues. Just as a comparison: All Harry Potter books together are around 1.1M words, ie. around 10M characters. Loading that (or even a 10 times larger document) into a QTextDocument should work without issues. But a 5G set of machine generated data? I would believe you want a special class handling that and loading data on the fly, so you have some memory left for the rest of your system. Having said that, I don’t mind changing our API to use qsizetype for QTextDocument, I just don’t believe you will find the class to be very snappy and usable with such large documents. The piece table itself should be able to handle it if you have enough RAM, but the default layout engine probably can’t (you could try using your own custom layout though). Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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) doesn't cache data, and only fetches and shows what's visible in its viewport. So the actual consumption is pretty much constant no matter how big is the underlying model. My 2 c, -- 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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 column > > count, files. > > > > Many of the text files we work with, are generated library definitions for > > silicon definitions. A 5+ gb file is not uncommon. Or files with a truth > > table definition with 5000-1000 columns. I kid you not. > > > > Its one thing to not handle it, and say "too big to open" its another to > > attempt to and crash because the internal integers cant handle it. > > > > Scintilla handles these massive files relatively easily. > > Yes, this files terms to be huge and are a valid case after all. Not disagreeing that huge files are valid. The question is whether the API needs to directly map to such huge files. When your data set becomes very big, the layer above those display classes should consider tiling or windowing the data. Let's take a simplest case: a 2 billion character QPlainTextEdit. The text alone is 4 GB in memory. QPlainTextEdit (through QTextDocument) will also parse all the lines in the text and create blocks for them, whether they're visible or not. So not only will this require a lot of memory, it will also be very slow. 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. So, I don't dispute the need to *index* very large data sets. I do dispute the need for a single Qt graphical class to keep the entire data set parsed, in memory. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 QStrings or
> QList
>
> 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 unlikely.
>
> 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 column
> count, files.
>
> Many of the text files we work with, are generated library definitions for
> silicon definitions. A 5+ gb file is not uncommon. Or files with a truth
> table definition with 5000-1000 columns. I kid you not.
>
> Its one thing to not handle it, and say "too big to open" its another to
> attempt to and crash because the internal integers cant handle it.
>
> Scintilla handles these massive files relatively easily.
>
Yes, this files terms to be huge and are a valid case after all.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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:
> > 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 unlikely.
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 column count, files.
Many of the text files we work with, are generated library definitions for
silicon definitions. A 5+ gb file is not uncommon. Or files with a truth
table definition with 5000-1000 columns. I kid you not.
Its one thing to not handle it, and say "too big to open" its another to
attempt to and crash because the internal integers cant handle it.
Scintilla handles these massive files relatively easily.
Scott
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 support "forever". Qt 7 (or 6.N for a big enough value of N) would use a size_t-sized qsizetype exclusively. My 2 c, -- 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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
A new Document API where you could memory map the file and save the changes as
a log on top would be nice. For lines you have to read the file but you don't
have to hold it completely in memory. An other advantage would be that your
document would be a binary reflection of the file. But I think 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 questionable. Editing a text file with more than 2G
>> characters? Sounds unlikely.
>
> Thou Shalt Not Write Debug Log Viewers Or Hex Editors With Qt. :)
Porting that API might not be too much of a problem, I don’t think we have
virtual methods in there taking offsets.
But QTextDocument is probably not the right data structure for a hex editor or
a log viewer anyway (why would you store a hex in clear text instead of
decoding on the fly???).
Cheers,
Lars
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
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 questionable. Editing a text file with more than 2G
>> characters? Sounds unlikely.
>
> Thou Shalt Not Write Debug Log Viewers Or Hex Editors With Qt. :)
Porting that API might not be too much of a problem, I don’t think we have
virtual methods in there taking offsets.
But QTextDocument is probably not the right data structure for a hex editor or
a log viewer anyway (why would you store a hex in clear text instead of
decoding on the fly???).
Cheers,
Lars
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 unlikely.
Thou Shalt Not Write Debug Log Viewers Or Hex Editors With Qt. :)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 in their interfaces?
> 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]
> Or you have to plaster your code with casts. E.g. every time you pass an
> index of your container to your model class.
>
> Some classes which are probably affected:
> QtCore:
> * QAbstractItemModel and subclasses (using QList or std::vector as data
> storage)
> * QModelIndex
I don’t think we should port these to use qsizetype.
> * QRegularExpression (match offset)
> * QStringMatcher
> * QSyntaxHighlighter
> * QTextBoundaryFinder
> * QXmlString::size
I think we should still fix these, as they are in low level string processing
classes
> 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 unlikely.
>
> QtWidgets:
> * QAbstractItemView and subclasses
> * QLineEdit
Neither should we touch these IMO.
Cheers,
Lars
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
Or
for( auto ii = 0; ii < std::vector.size(); ++ii )
{
}
since there is no suffix for "size_t" and the size of size_t will depend on 64
vs 32 bits whats the best way to AAA the index iterator?
Scott
-Original Message-
From: Development [mailto:development-boun...@qt-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++ also has a solution for that problem: [1]
>
> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-al
> ways-auto/
AAA is a non-solution from the ivory tower.
It's a pain for human reviewers and tools operating on less then a full
translation unit.
(Almost) real-world example:
for (auto i = foo.guess_stuff(); --i >= 0; )
do_something(i);
Good? Bad?
Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 operating on less then a full translation unit. (Almost) real-world example: for (auto i = foo.guess_stuff(); --i >= 0; ) do_something(i); Good? Bad? Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 'int' [-Wshorten-64-to-32] > > I'm afraid that these warnings will be all over the place anyhow. Just how > much code has been written against int-based APIs? Depends on the nature of the application, but in a typical Qt application where GUI plays a major role, I would expect 'int' all over the place, As an example, Qt Creator code has 48715 hits for '\bint\b', 1191 '\bsize_t', most of the latter in 3rd party or test code. > 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. > But anyhow: yes, as a consistency factor, as many APIs as possible should be > ported to qsizetype. For us it was consistent so far. It is getting a pain only now. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 types, not least of which is they aren't practically useful anyway. Some consider it a mistake that size_t is unsigned, and indeed, ssize_t is starting to be retrofitted in some places (e.g. `container.ssize()`). If we ever get an STL2 it will likely also have signed index types. Signed index types allow things like indexing-from-end and make tests for invalid indices far less painful. Seriously, which of these do you prefer? if (s.find(ch) < 0) // option 1 if (s.find(ch) != std::string::npos) // option 2 -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 a huge list, tree or table? Just another thought -- models may not necessarily used directly with views but as data sources for other business logic parts of the application (including but not necessarily limited to proxy models). Given the underlying data sources are 64-bit capable, such models should be as well. Indeed; this is sort of the approach one of my applications takes. Although we do usually end up with a view on top of the model (often after a few levels of indirection¹), we also use models (i.e. QAbstractItemModel) to drive things like graphical displays. (It would take some words to explain our actual use case, but think of using a model as the source for a scatter plot and you sort-of get the idea.) That said, I suspect you would run into fairly severe performance problems trying to use a model with more than 2^31 rows... (¹ We generally have one model that presents the data in an abstract fashion, using data roles rather than columns as field identifiers. This separates what the data *is* from how it's presented. This may get fed into one or more sort/filter proxy models before being fed into a "representation" model, which folds, spindles and mutilates the fields-as-data-roles model into a fields-as-columns model suitable for being fed into e.g. QTreeView. One nice feature is that the representation can accept a list of what fields you want to have in the view.) -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 that works on `double`. Doesn't derive from QAbstractSlider because it can't. These are hardly uncommon; GIMP has tons of examples, for instance, in many, many filter options dialogs (although the widget they use isn't entirely like QSlider). Yes, you can sort-of emulate them with integers under the hood, but doing so adds an annoying level of dissonance to the code. Q[Abstract]Slider being limited to `int` is indeed an irritation. We have QDoubleSpinbox, why not QDoubleSlider? -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 audio domain, it's common to have audio > files with more than 2 billions audio samples (long recordings). > I had the wish to display to the user the level of individual audio > samples, for analysis purposes. Thank you, that is indeed a valid use-case. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 may not necessarily used directly with views but as data sources for other business logic parts of the application (including but not necessarily limited to proxy models). Given the underlying data sources are 64-bit capable, such models should be as well. My 2 c, -- 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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 paging splits the data which is poor UX too. Of course, to make it usable, you have to add filters on top of that, but you’d probably need them anyway while paging is just an overcomplicating with no gain. Note that the model might not contain the data but retrieve it upon request from the view, e.g. store some cache. An example of such a huge model can be the hex model that displays the contents of the file. Normally, files are not that big, but they are theoretically possible. Of course, one can say that «nobody needs» it, that this is corner use-case… Well, libraries have to support corner use-cases, haven’t they? Ivan > 25 авг. 2020 г., в 01:09, 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 suppose, it is not very hard to patch >> QModelIndex, but what to do with virtual functions? The user code will >> break. The only solution I see is to add QAbstractItemModelV2 with the >> «wide» interface and provide a proxy for the old one. > > Do we need models with more than 2 billion rows or columns? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 suppose, it is not very hard to patch QModelIndex, but what to do with virtual functions? The user code will break. The only solution I see is to add QAbstractItemModelV2 with the «wide» interface and provide a proxy for the old one. Do we need models with more than 2 billion rows or columns? Not really, but 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. So what. Ciao Mathias ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
> 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 billions audio samples (long recordings). I had the wish to display to the user the level of individual audio samples, for analysis purposes. Philippe On Mon, 24 Aug 2020 22:49:42 -0700 Thiago Macieira wrote: > 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 than 2 billion items are rare, but I see it happening > for > QByteArray and QString at least. > > 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? > > > 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 QAbstractSlider be able to > > handle 64 bit quantities too. > > How does that make a good UX? > > On an 8k resolution (7680 × 4320), each vertical pixel would represent half a > million entries. > > I'm not questioning the existence of data sets of more than 2 billion > entries. > Those exist. I'm asking how one can make a UX that requires more than 2 > billion rows or columns. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 than 2 billion items are rare, but I see it happening for QByteArray and QString at least. 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? > 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 QAbstractSlider be able to > handle 64 bit quantities too. How does that make a good UX? On an 8k resolution (7680 × 4320), each vertical pixel would represent half a million entries. I'm not questioning the existence of data sets of more than 2 billion entries. Those exist. I'm asking how one can make a UX that requires more than 2 billion rows or columns. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
> 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 QAbstractSlider be able to handle 64 bit quantities too. Philippe On Mon, 24 Aug 2020 16:09:57 -0700 Thiago Macieira wrote: > 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, but what to do with virtual functions? The user code will > > break. The only solution I see is to add QAbstractItemModelV2 with the > > «wide» interface and provide a proxy for the old one. > > Do we need models with more than 2 billion rows or columns? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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, but what to do with virtual functions? The user code will > break. The only solution I see is to add QAbstractItemModelV2 with the > «wide» interface and provide a proxy for the old one. Do we need models with more than 2 billion rows or columns? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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.
The only solution I see is to add QAbstractItemModelV2 with the «wide»
interface and provide a proxy for the old one.
Ivan
> 23 авг. 2020 г., в 16:06, Marcel Krems написал(а):
>
> 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: implicit conversion loses integer precision: 'qsizetype' (aka 'long
> long') to 'int' [-Wshorten-64-to-32]
> Or you have to plaster your code with casts. E.g. every time you pass an
> index of your container to your model class.
>
> Some classes which are probably affected:
> QtCore:
> * QAbstractItemModel and subclasses (using QList or std::vector as data
> storage)
> * QModelIndex
> * QRegularExpression (match offset)
> * QStringMatcher
> * QSyntaxHighlighter
> * QTextBoundaryFinder
> * QXmlString::size
>
> QtGui:
> * QTextCursor
> * QTextDocument (find offset, character{At,Count})
> * QTextLayout
> * QValidator and subclasses (validate offset)
>
> QtWidgets:
> * QAbstractItemView and subclasses
> * QLineEdit
>
>
> Kind regards,
> Marcel
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 'long long') to 'int' [-Wshorten-64-to-32] I'm afraid that these warnings will be all over the place anyhow. Just how much code has been written against int-based APIs? (For the record, that's why I wanted a configure time switch to choose the size of qsizetype). But anyhow: yes, as a consistency factor, as many APIs as possible should be ported to qsizetype. Could you please file a bug report? Thanks, ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 them all, I guess this is as good as it gets: https://codereview.qt-project.org/q/message:qsizetype My 2 c, -- 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 > > > > auto x = foo(); // this always compiles > > ... > > ... > > ... > > some_use_of(x); // you may detect an API break here, or somewhere deep > > inside some_use_of > > > > I wonder where the verifiable evidence is that AAA works at scale. > > What about: > > some_use_of(foo()); > > Are you suggesting that this is an anti-pattern? I fail to see where I might have suggested such a thing. That sort of uses are unaffected by whether an API user does or does not buy into AAA. They certainly are another way to detect (or suffer from) an API break, and trying to use more auto doesn't solve it. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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. The very reason for not using deduced > > > types is to detect API breaks loudly. > > > The warning does that in dulcet tones, not as loudly as some might > > > wish because the conversion is implicit. > > > Buying the AAA snake oil can move the problem elsewhere for a while, > > > but it's not helpful; it's partially > > > hiding an API break, and it's unlikely that you want that to continue; > > > the manifestations of the API break > > > are going to appear further away from the spots where they could be > > > first detected. > > > > Do you have examples showing verifiable evidence, or do you share a feeling? > > 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 > > auto x = foo(); // this always compiles > ... > ... > ... > some_use_of(x); // you may detect an API break here, or somewhere deep > inside some_use_of > > I wonder where the verifiable evidence is that AAA works at scale. What about: some_use_of(foo()); Are you suggesting that this is an anti-pattern? Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 loudly. > > The warning does that in dulcet tones, not as loudly as some might > > wish because the conversion is implicit. > > Buying the AAA snake oil can move the problem elsewhere for a while, > > but it's not helpful; it's partially > > hiding an API break, and it's unlikely that you want that to continue; > > the manifestations of the API break > > are going to appear further away from the spots where they could be > > first detected. > > Do you have examples showing verifiable evidence, or do you share a feeling? 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 auto x = foo(); // this always compiles ... ... ... some_use_of(x); // you may detect an API break here, or somewhere deep inside some_use_of I wonder where the verifiable evidence is that AAA works at scale. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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: 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. Just how much code has been written against int-based APIs? (For the record, that's why I wanted a configure time switch to choose the size of qsizetype). But anyhow: yes, as a consistency factor, as many APIs as possible should be ported to qsizetype. Could you please file a bug report? 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 loudly. The warning does that in dulcet tones, not as loudly as some might wish because the conversion is implicit. Buying the AAA snake oil can move the problem elsewhere for a while, but it's not helpful; it's partially hiding an API break, and it's unlikely that you want that to continue; the manifestations of the API break are going to appear further away from the spots where they could be first detected. Do you have examples showing verifiable evidence, or do you share a feeling? Ciao Mathias ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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 precision: 'qsizetype' (aka > 'long long') to 'int' [-Wshorten-64-to-32] > > > I'm afraid that these warnings will be all over the place anyhow. Just how > much code has been written against int-based APIs? (For the record, that's > why I wanted a configure time switch to choose the size of qsizetype). > > But anyhow: yes, as a consistency factor, as many APIs as possible should be > ported to qsizetype. Could you please file a bug report? > > 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 loudly. The warning does that in dulcet tones, not as loudly as some might wish because the conversion is implicit. Buying the AAA snake oil can move the problem elsewhere for a while, but it's not helpful; it's partially hiding an API break, and it's unlikely that you want that to continue; the manifestations of the API break are going to appear further away from the spots where they could be first detected. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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] I'm afraid that these warnings will be all over the place anyhow. Just how much code has been written against int-based APIs? (For the record, that's why I wanted a configure time switch to choose the size of qsizetype). But anyhow: yes, as a consistency factor, as many APIs as possible should be ported to qsizetype. Could you please file a bug report? C++ also has a solution for that problem: https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ Ciao, Mathias ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
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. Just how much code has been written against int-based APIs? (For the record, that's why I wanted a configure time switch to choose the size of qsizetype). But anyhow: yes, as a consistency factor, as many APIs as possible should be ported to qsizetype. Could you please file a bug report? 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
