[odb-users] How to make a "lazy" QList?

Boris Kolpackov boris at codesynthesis.com
Wed Nov 7 08:43:42 EST 2012

Hi Rene,

Rene Jensen <rene at catatonic.dk> writes:

> I suppose we can agree on these two claims:
> ad 1) Items should be stored in such a way that existing API's can make use
> of them.
> ad 2) If the user has direct access to a well-known QList, std::vector...
> then there is no way to know what he has done, thus update means: REMOVE

Yes, that makes sense.

> Put (1) inside (2). In you suggestion it would mean having an
> odb::qt::QList as the manager which internally manages a traditional
> QList. For purposes of reading, the user would be able to gain access
> to the stored QList.

Yes, that is the idea. I think we can support what I would call "const
inheritance" from QList by providing an implicit conversion operator
to const QList&. This way odb::QList would behave as if it was derived
from QList's const interface.

> Put (1) next to (2).

I don't think this is a good idea from the safety point of view. It is
too easy to forget that all modifications has to go through the manager
and modify the container directly.

> As long as the user can A) control which underlying collection type is
> used,

I think this will just complicate things since in each case we would want
to mimic the original container's interface as closely as possible. Why
not just have odb::QList which is based on QList, std::vector which is
based on std::vector, etc? This way ODB versions are just drop-in
replacements for Qt/standard containers.


More information about the odb-users mailing list