Quote Originally Posted by rickbsgu View Post
That's the whole point, is you don't have redundant data.
Qt Code: 
  1. YourModel model;
  2. //...
  3. void *ptr1 = 0;
  4. {
  5.   QModelIndex ind1 = model.index(1,1); // assuming the same parent index everywhere
  6.   QModelIndex ind2 = model.index(1,1); // not invisible root item of course
  7.   ptr1 = ind1.internalPointer();
  8.   void *ptr2 = ind2.internalPointer();
  9.   bool result = (ptr1==ptr2); // true or false?
  10.   if(result){
  11.     // assuming it's true and both indexes created independently share some data
  12.     void *ptr3 = 0;
  13.     { 
  14.       // artificial scope
  15.       QModelIndex ind3 = model.index(1,1);
  16.       ptr3 = ind3.internalPointer();
  17.     }
  18.     // here ind3 is destroyed, ptr3 points to ptr1 and ptr2 based on "result"
  19.     InternalPointer * iptr = (InternalPointer*)ptr3;
  20.     iptr->doSomething(); // segfault or not? ptr3 still valid or not?
  21.   }
  22. }
  23. QModeIndex ind4 = model.index(1,1);
  24. void *ptr4 = ind4.internalPointer();
  25. bool result2 = (ptr1==ptr4); // true or false?
  26. if(!result2)
  27.   for(int i=0;i<1000;i++) QModelIndex tmpIndex = model.index(1,1); // slow or fast?
To copy to clipboard, switch view to plain text mode 


It's a non-issue on Intel.
Hmm?

Qt Code: 
  1. #include <stdio.h>
  2.  
  3. struct S1 {
  4.   unsigned char s;
  5.   int i;
  6. };
  7.  
  8. struct S2 {
  9.   unsigned char s;
  10. };
  11.  
  12. struct S3 {
  13.   unsigned char s;
  14.   int i;
  15. } __attribute__((__packed__));
  16.  
  17. int main(){
  18.   struct S1 x;
  19.   struct S2 x2;
  20.   struct S3 x3;
  21.   printf("Struct S1 size: %d\n", sizeof(x));
  22.   printf("Struct S2 size: %d\n", sizeof(x2));
  23.   printf("Struct S3 size: %d\n", sizeof(x3));
  24.   return 0;
  25. }
To copy to clipboard, switch view to plain text mode 

$ uname -m
i686
$ gcc tst.c -o tst
$ ./tst
Struct S size: 8
Struct S2 size: 1
Struct S3 size: 5

Care to comment?


When it wants a parent index, it gives you the index it has on hand for the item for which it wants a parent.
It is not "back". parent() is const, thus the direction is maintained (data pulled, not pushed).

Consider this:
Qt Code: 
  1. QModelIndexList selected = view->selectedIndexes(); // index(1,1)_copy1 in the list (shallow copy)
  2. while(!selected.isEmpty()){
  3.   QModelIndex tmp = view->currentIndex(); // index(1,1)_copy3, index(1,1)_copy2
  4.   if(tmp==selected.value(0)){ // value returns index(1,1)_copy4
  5.     qDebug() << selected.value(0); // index(1,1)_copy5
  6.   }
  7.   selected.removeFirst(); // list modified, deep copy (index(1,1)_copy6)
  8. }
To copy to clipboard, switch view to plain text mode 
Six distinct instances of an index pointing to the same item - model not changed, multiple copies of the same index, some of them completely independent of each other (data couldn't be shared even with QSharedData). To make things worse:
Qt Code: 
  1. QModelIndexList selected = view->selectedIndexes();
  2. foreach(QModelIndex iter, selected){
  3.   model.removeRow(iter.row(), iter.column(), iter.parent());
  4. }
  5.  
  6. QModelIndex iter = selected.at(0); // index invalid, was deleted earlier
  7. while(iter.parent()!=view->rootIndex()){
  8.   qDebug() << iter.data(Qt::DisplayRole);
  9.   iter = iter.parent();
  10. }
To copy to clipboard, switch view to plain text mode 

If parent() doesn't use information from the model but instead only the info contained in the index the second iteration won't know the item is no longer valid (here you have the index fed "back") and will go crazy (point to some completely different data at least). If it did use some info from the model (regardless of the nature of the data), and the model is aware that its item has been removed, it can return an invalid parent() index. So if you want your model to be safe, you have to get the data from the model and not from the index. My explanation might not be clear (it's late here) - in that case forget it and move on.

Seems like it would be nefarious if it did.
Wrong! Something that seems logical is not necessary optimal and may change in future when speed becomes an issue. Bubble Sort is logical, Quick Sort is fast, std::sort() doesn't assume implementation.

I've got a lot of processes running on my machine, including two virtual machines
Irrelevant. Try allocating and using large blocks of continuous memory (like 1GB each). Virtual memory (furthermore clean not dirty one!) and physical memory are quite different things. No page faults until you access a particular block, no point in allocating a physical page for the process - virtual memory usage high, physical - none. Memory fragmentation is also a factor - it's much easier to allocate a little block than a big one. Much less an issue when allocating on stack. Uncontrolled and unpredictable (random) test conditions can't prove anything. Let's drop the example and focus on testable things like the sizeof() code I provided.