deleting internal pointer in QModelIndex

[rickbsgu]

[code]YourModel model;

Ok, I think you're maintaining here that the ModelIndexes get copied internally, and that copies get destroyed, willy-nilly, leaving some valid MI's around with the same internal pointer/id.

That certainly does kill the idea of trusting them with a piece of memory - you'd have to implement a ref system that would be sensitive to copies and all of that - certainly adds more weight to the MI's.

On Word Boundary Alignment/Packed Structures

Hmm?

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

Care to comment?

Blow me down! Two errors on my part:

1. I'm used to the MS compiler on Intel, and the automatic inclusion of the 'Zp1' arg, which packs structs. Have taken that somewhat for granted.
2. Was thinking more of passing arg word alignment issues vs. pack structs (which I don't think are an issue on Intel - you can prove me wrong with an example... )

That said, a word devoted to back-pointer is still a word devoted to back-pointer, and is still 4bytes on a 32bit machine, and 8 bytes on a 64bit machine. Not a big deal for small models - a huge deal for large models.

It is not "back". parent() is const, thus the direction is maintained (data pulled, not pushed).

Ok, here's where I don't understand. Consider this:

void *data;
mymodel::index(...)
{
  /*  ( stack frame pushed for this call ) */
  ....
  return createIndex(r,c,data);
  /*  ( stack frame pushed and popped for create call,
   |     popped again on return.  */
  ...
}
 
mymodel::parent(..., parent)
{
  ...
  if (parent.isValid)
  {
    void* parentData = parent.internalPointer();
    if (parentData == data)
      qdebug("Isn't this the modelitem I created above?");
  }
}

void *data;
mymodel::index(...)
{
  /*  ( stack frame pushed for this call ) */
  ....
  return createIndex(r,c,data);
  /*  ( stack frame pushed and popped for create call,
   |     popped again on return.  */
  ...
}

mymodel::parent(..., parent)
{
  ...
  if (parent.isValid)
  {
    void* parentData = parent.internalPointer();
    if (parentData == data)
      qdebug("Isn't this the modelitem I created above?");
  }
}

To copy to clipboard, switch view to plain text mode 

I guess I could prove the latter question by hanging on to the pointer of
the created MI and see if it's the same. At any rate, if the ModelItem is not fed back to me, something that looks very much like it is.

Consider this: (two really interesting coding examples)

Ok, I'm studying these. Again, the crux appears to be that copies are happening spontaneously all over the place, is that correct?

So, again (if true), I agree - it kills the idea of handing a piece of memory to the ModelItem. (Beyond performance questions.)

<...snip...>
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.

I don't think we disagree, here: The real information is coming from the model - in the small structure context I've questioned about, the little items aren't data - they're just pointer holders. You can think of them as large pointers that have to be allocated. I'm expecting them to die quickly, I'm not expecting to hang on to them, I'm not expecting them to be valid any longer than the index (which, as we have discussed, is very short-lived.)

But, again, if they're (the MI's) being copied internally and the dups are being destroyed, that certainly puts a hole in the notion. That's a valid issue.

cheers,
rickb