[Qt-interest] Handle object deletions right with containers (not-working stripped example)

[Wilhelm]

Hi,

Am 08.08.2011 13:46, schrieb Bo Thorsen:
> First of all, you are correct that you have to call beginRemoveElement 
> before deleting your object, unless you work around this. You could for 
> example mark an object being deleted as unavailable, so if one of the 
> views or proxies call data() or something else, you just return default 
> values for it. That's a workaround that often works with these pointer 
> based models.

yes, I thought of this too, but this leads to other problems.

If the contained objects are removed the "normal" way, e.g. calling a
remove()-method, this works.

If the contained objects are deleted "outside", this approach requires,
that the container (model) caches some information about the deleted
objects, because at the moment the destroyed() signal is emitted, the
subclassed-parts aren't available anymore. If you call
beginRemoveElements() (as in the QAbstractItemModel example) in that
moment, the rowsAboutToBeRemoved() signal is emitted, what in turn
triggers interested objects (views) to query information and they assume
to get the state *before* the removal but the detail information isn't
available anymore ...

> 
> To me this looks like an example where I would not use a signal slot 
> connection for the deletes. Instead, as the first thing you do in the 
> destructor of the contained object, call the deletingObject(this) on the 
> model and do the removes.

Well, that requires tightly coupled classes (the contained object must
know the container). Therefore this approach isn't feasable.

> 
> Both of these approaches are valid. If you have a tree of contained 
> objects, I'd go with the first of them. If you have only a single 
> contained class, I'd choose the second.
> 
> Bo.
> 
> Den 08-08-2011 08:14, Wilhelm skrev:
>> Hi,
>>
>> the attached example is motivated by working with QAbstractItemModel /
>> QProxyModel (writing a proxy model that can combine other models) but
>> not limited to.
>>
>> In the example class Container holds pointers to objects, but does not
>> own(!) these objects. Any removal (and addition) of pointers results in
>> sending signals beginRemoveElement() / endRemoveElement() (as in
>> QAbstractItemModel).
>>
>> The problem arises if one of the objects are deleted without removing it
>> first. I want to make this situation safe because the Container does not
>> own the objects. I use the QObject::destroyed() signal connected to slot
>> Container::elementDeleted(). But clearly this results in a crash calling
>> Container::remove().
>>
>> So, how to handle this situation (bearing in mind that I'm looking for a
>> solution with QAbstractItemModel, where I have a similar situation
>> calling beginRemoveRows() / endRemoveRows())?
>>
>>
>>
>>
>> _______________________________________________
>> Qt-interest mailing list
>> Qt-interest at qt.nokia.com
>> http://lists.qt.nokia.com/mailman/listinfo/qt-interest
> 
> 
> Bo Thorsen,
> Fionia Software.
> 


-- 
Wilhelm