deleting internal pointer in QModelIndex

[rickbsgu]

The point is it's not worth it to have shortlived objects owned by indexes. There are really no benefits of that.

Ok, it seems like it would be worth it, if they can help the model divine the information they want. And, if they go away, they're not using up any resources outside of the Qt-required context.

That's bad then. The data remains valid as long as the model doesn't change, thus there is no point in deleting it just to create it again in a moment. If you want such volatile cache - implement it in the model, it knows better when data can or has to be destroyed.

Again, I don't think it's bad. The MIs are short lived, there's no reason a tag-along piece of information can't be just as short-lived. The best analogy I could come up with was the 'big pointer' analogy - they're not model data, per se. And, if the memory manager is just going to dole out the same pointers from a pool, so much the better.

(However: your index.parent().parent()... example in another thread is something to think about. Nothing better than going back to the original data - can't argue that.)

Stack Allocator
So, I walked through 'createIndex()' to see what it does. Nothing particularly magical. As you say, it creates the struct on the stack. The trick is that it relies on the copy constructor to fill each instance up the stack. Makes sense in a 'slap-your-forehead', 'of-course!' sort of way, when you see it.

I created an example that uses the same construct to play with - you can watch the values being copied up the stack (in the debugger) as each frame backs out.

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.

Tried both ms and gnu compilers - same behavior. Here's the code, if you're interested:

#include <iostream>
 
using namespace std;
 
class TT
{
  friend class A;
 
  public:
    ~TT() { cout << "Destroyed!!" << endl; }
 
    int A() { return a; }
    int B() { return b; }
    int C() { return c; }
    int D() { return d; }
 
  private:
    int a, b, c, d;
    TT(int _a, int _b, int _c, int _d)
      { a = _a, b = _b, c = _c, d = _d; }
};
 
class A
{
  public:
    TT createTT(int a, int b, int c, int d) { return TT(a,b,c,d); }
 
    void init_A()
    {
      TT item = getItemFromB();
      cout << "TT item: " << item.A() << ", " << item.B() << ", "
                         << item.C() << ", " << item.D() << endl;
    }
 
    virtual TT getItemFromB() = 0;
};
 
class B : public A
{
  public:
    virtual TT getItemFromB()
      { return createTT(1, 2, 3, 4); }
};
 
int main (int argc, char **argv)
{
  B b;
  b.init_A();
  return 0;
}

#include <iostream>

using namespace std;

class TT
{
  friend class A;

  public:
    ~TT() { cout << "Destroyed!!" << endl; }

    int A() { return a; }
    int B() { return b; }
    int C() { return c; }
    int D() { return d; }

  private:
    int a, b, c, d;
    TT(int _a, int _b, int _c, int _d)
      { a = _a, b = _b, c = _c, d = _d; }
};

class A
{
  public:
    TT createTT(int a, int b, int c, int d) { return TT(a,b,c,d); }

    void init_A()
    {
      TT item = getItemFromB();
      cout << "TT item: " << item.A() << ", " << item.B() << ", "
                         << item.C() << ", " << item.D() << endl;
    }

    virtual TT getItemFromB() = 0;
};

class B : public A
{
  public:
    virtual TT getItemFromB()
      { return createTT(1, 2, 3, 4); }
};

int main (int argc, char **argv)
{
  B b;
  b.init_A();
  return 0;
}

To copy to clipboard, switch view to plain text mode 

Anyway, I need to get on to my little demo and try to get it coded up before the universe collapses.

Thanks for the discussion. As always, C++ (and Qt) gives me something new to chew on when I dig under the covers.

Cheers,
rickb

[wysota]

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:

private:
ExtraData cache[128];
//...
QModelIndex Model::index(...){
  id = getCachedExtraDataFor(row, column, parent);
  return createIndex(row, column, id); // this version uses the internalId instead of internalPointer
}

private:
ExtraData cache[128];
//...
QModelIndex Model::index(...){
  id = getCachedExtraDataFor(row, column, parent);
  return createIndex(row, column, id); // this version uses the internalId instead of internalPointer
}

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