Quote Originally Posted by rickbsgu View Post
The MIs are short lived, there's no reason a tag-along piece of information can't be just as short-lived.
"Can" and "should" are different things. Why destroy data that is perfectly valid and can be reused a moment later? Caches rarely delete data, instead they overwrite it with new data or mark old data as invalid. You can implement a simple cache in the model like so:
Qt Code:
  1. private:
  2. ExtraData cache[128];
  3. //...
  4. QModelIndex Model::index(...){
  5. id = getCachedExtraDataFor(row, column, parent);
  6. return createIndex(row, column, id); // this version uses the internalId instead of internalPointer
  7. }
To copy to clipboard, switch view to plain text mode 
Here you have a simple 128 element cache that keeps data for 128 indexes (you can use a QVector and resize it if needed). You can then pass the index of the cache to the model index and be able to retrieve the extra data quickly when you need it. Of course the type of cache is irrelevant here (set, associative or mixed) just be aware you have to be able to tell if you hit or missed the cache before using the stored data. In the latter case you need to construct the extra data from scratch and store it in the cache. Of course the cache flicker issue steps in here, so it's your responsibility to design the cache properly.

A curiosity, though - I'm watching the destructor. I would expect the destructor to get called as it backs out of each frame (the frame's instance gets destroyed.) Instead, it only gets destroyed when the calling instance backs out. That's odd. It's almost as if there's a ref count on it.
Maybe that's how the compiler handles const references?


Anyway, I need to get on to my little demo and try to get it coded up before the universe collapses.
I heard someone whisper it won't happen before 2012, so you have still some time. And by then Qt5.0 will be out