What are the downsides of a QAbstractListModel containing objects in QML?

Question

Qt offers the possibility to combine C++ models with QML and suggests three approaches in the docs:

• QStringList
• QObjectList

Answer 1

The one prominent downside of the usage of QObject as a model item is because the base class is pretty big, it is kind of a "god object" (which is an anti-pattern) that contains a whole lot of stuff you don't really need most of the time. As a result, it has about 160 bytes of "overhead" on top of any model data that you may have. Which may be problematic if you have a big model with lots of items, and the items themselves are relatively small. You end up with a lot of overhead.

A QObjectList as a model is always a bad idea, unless you are doing something entirely trivial. Since it doesn't implement the proper interface to notify referencing views of changes, the only way is to force an update, which will redraw the entire model each time rather than just the changes.

There is no requirement on what item objects are, as long as you implement the model properly.

The second implementation in particularly useful for a number of reasons:

• you don't need to bother with implementing a specific "static" model with fixed roles for each and every usage scenario
• your model items can have fundamentally different properties, you are not limited to a model "schema"
• you automatically get notifications for bindings in QML since you are dealing with QObject and Q_PROPERTY
• you can define models in declarative, and you can even nest models to create tree structures, which you cannot do with ListModel.
• you can define the actual model items in pure QML without having to recompile all the time, a.k.a rapid prototyping, and when done, you can simply port the objects to C++
• at the same time, on top of all the advantages, the model is actually much simpler to implement and maintain than a regular "rigid" model, the role lookup is faster, since you essentially have a single object role and no lookup whatsoever, there is no need to implement data change signals for roles and so on... easy peasy