Results 1 to 19 of 19

Thread: deleting internal pointer in QModelIndex

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #17
    Join Date
    Jan 2006
    Location
    Earth (Terra)
    Posts
    87
    Thanks
    4
    Thanked 6 Times in 4 Posts
    Qt products
    Qt4 Qt5
    Platforms
    MacOS X Unix/X11 Windows Symbian S60

    Default Re: deleting internal pointer in QModelIndex

    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:

    Qt Code:
    1. #include <iostream>
    2.  
    3. using namespace std;
    4.  
    5. class TT
    6. {
    7. friend class A;
    8.  
    9. public:
    10. ~TT() { cout << "Destroyed!!" << endl; }
    11.  
    12. int A() { return a; }
    13. int B() { return b; }
    14. int C() { return c; }
    15. int D() { return d; }
    16.  
    17. private:
    18. int a, b, c, d;
    19. TT(int _a, int _b, int _c, int _d)
    20. { a = _a, b = _b, c = _c, d = _d; }
    21. };
    22.  
    23. class A
    24. {
    25. public:
    26. TT createTT(int a, int b, int c, int d) { return TT(a,b,c,d); }
    27.  
    28. void init_A()
    29. {
    30. TT item = getItemFromB();
    31. cout << "TT item: " << item.A() << ", " << item.B() << ", "
    32. << item.C() << ", " << item.D() << endl;
    33. }
    34.  
    35. virtual TT getItemFromB() = 0;
    36. };
    37.  
    38. class B : public A
    39. {
    40. public:
    41. virtual TT getItemFromB()
    42. { return createTT(1, 2, 3, 4); }
    43. };
    44.  
    45. int main (int argc, char **argv)
    46. {
    47. B b;
    48. b.init_A();
    49. return 0;
    50. }
    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
    Last edited by rickbsgu; 18th December 2007 at 21:57.

Similar Threads

  1. Replies: 6
    Last Post: 21st September 2007, 13:51
  2. Replies: 2
    Last Post: 16th February 2006, 19:09

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Qt is a trademark of The Qt Company.