Storing shared pointer in QModelIndex

[anda_skoa]

The "internal" stuff in a QModelIndex is internal to the respective model instance.
I.e. any model function that gets a QModelIndex passed as an argument, can first check if model() is "this".
If it is, it can work with either internalId() or internalPointer() knowing that itself and nobody else put that info into the model index.

Also keep in mind that this lookup structure can be purged or at least cleaned in a lot of cases.

Anything that modifies the model, be it setData() or inserting/removing rows, etc. is assumed to invalidate all model indexes.
So any mapping that is kept for QModelndex -> internal data lookup could be invalidated at these times as well.
(might have to check for persistent model indexes though).

Event processing is also assumed to be invalidate model indexes, so one can also clear those mappings based on a timer.

Cheers,
_

[d_stranz]

My QAbstractItemModel that wraps my C++ tree structure is intended to be read-only (i.e. no editing, display only). When the external tree changes, I do a reset on the model (and will clear the smart pointer map). So any model indexes stored as persistent indexes will go away.

I guess I am interested in the more general case - what are best practices to use when mating an external data structure to a QAbstractItemModel? It seems that QStandardItemModel is about the only one that has built-in support for storing some reference to external user data into the model itself.

The most complete example of a custom tree model I have found is from Summerfield's "Advanced Qt Programming", and he uses internalPointer() to store pointers to his tree items.

[anda_skoa]

The QStandardItemModel actually stores the data it serves.
Usually this is not what you want, instead the QAIM subclass is used as an interface to the actual data.

Yes, it is a pity that QModelIndex cannot hold a QVariant as its reference.
But then again, a QVariant is basically just a void* plus type information and type information is what the model has implicitly since it knows what it puts into its indexes.
The only missing bit is that the model doesn't know when the model index gets destroyed so it can't use this for cleanup triggering and has to resort to different means.

Well, "only" because this is really annoying.

Cheers,
_