[Development] qsizetype and classes working with QStrings or QList

[Matthew Woehlke]

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