How QSharedPointer works?
-
I have QList<QSharedPointer<MyClass>>. I use elements of the list by creating a new (not a keyword) QSharedPointer<MyClass> newPointer = list.at(x); Then I pass it around and do the work, then the pointer dies but I have an extra one in the list so everything's fine, right? I noticed the destructor of MyClass is called after I leave the pointer in the list for a while, I don't understand why or when exactly... then I'm finding QSharedPointer inside the list but raising exception on list.at(x).data(); Researching the issue I found this: "[Pointer tracking] allows one to catch mistakes like assigning the same pointer to two QSharedPointer objects." - how is that a mistake? Why would I need a smart pointer like that if not to have many copies of it and expect the data to be removed as last of them goes out of scope? Do I completely misunderstood how QSharedPointer work and what problem are they solving?
-
QSharedPointer deletes (as std::shared_ptr) the object when it is no longer referenced. So what you're telling looks some kind of strange. Therefore please show us some code or even better - write a small testcase to reproduce the problem.
-
I have QList<QSharedPointer<MyClass>>. I use elements of the list by creating a new (not a keyword) QSharedPointer<MyClass> newPointer = list.at(x); Then I pass it around and do the work, then the pointer dies but I have an extra one in the list so everything's fine, right? I noticed the destructor of MyClass is called after I leave the pointer in the list for a while, I don't understand why or when exactly... then I'm finding QSharedPointer inside the list but raising exception on list.at(x).data(); Researching the issue I found this: "[Pointer tracking] allows one to catch mistakes like assigning the same pointer to two QSharedPointer objects." - how is that a mistake? Why would I need a smart pointer like that if not to have many copies of it and expect the data to be removed as last of them goes out of scope? Do I completely misunderstood how QSharedPointer work and what problem are they solving?
@Szymon-M-Sabat said in How QSharedPointer works?:
"[Pointer tracking] allows one to catch mistakes like assigning the same pointer to two QSharedPointer objects." - how is that a mistake?
int *my_pointer = new int; some_shared_pointer foo(my_pointer); some_shared_pointer bar(my_pointer);Foo and Bar might look like they are sharing with each other, but they aren't! Bar has no idea that foo already thinks it's responsible for the pointer. Because bar wasn't specifically made from foo using the right copying API, it thinks it was created from scratch, and it owns the pointer all by itself. Subsequent shared pointers made from either foo or bar will be in separate little ref counting universes, and when either foo or bar thinks that the ref count is zero, it'll try to delete my_pointer. Even if the other refcount thinks there are a thousand objects still using it.
int *my_pointer = new int; some_shared_pointer foo(my_pointer); some_shared_pointer bar(foo);This time, bar is made from foo instead of from the original bare pointer, so it shares the refcount, and won't explode unpredictably. This is what your original quote was talking about. Having another shared pointer ultimately derived from the same address is good and correct. Having two shared pointers directly assigned authority over the actual address will result in them fighting, and your application will be caught in the crossfire. The obvious followon question is couldn't somebody make a smart pointer class that uses some sort of clever global registry of addresses? And the answer is only-sorta, but the performance implications would be horrific for something intended to be quite efficient, so you should solve the ownership problem elsewhere.
Use the debugger to set a breakpoint in your class destructor to figure out who is actually deleting it to get a better understanding of what's currently happening..
-
QSharedPointer deletes (as std::shared_ptr) the object when it is no longer referenced. So what you're telling looks some kind of strange. Therefore please show us some code or even better - write a small testcase to reproduce the problem.
@Christian-Ehrlicher okay, so I've found out what I did wrong. I was getting a raw pointer by other means (signal-slot mechanism and the sender() function) and I constructed QSharedPointer based on that raw pointer so the other pointer didn't know about it (as I understand it). I needed to use the raw pointer to iterate over my list to find the original QSharedPointer and build the new one using it. Marking as solved, thanks for clarifying that the pointers work as I understood they should.
@wrosecrans wrote exactly what happened. Thank you! I think the docs could include your description.
-
@Szymon-M-Sabat said in How QSharedPointer works?:
I think the docs could include your description.
It is - see https://doc.qt.io/qt-5/qsharedpointer.html#QSharedPointer-1 :
The pointer ptr becomes managed by this QSharedPointer and must not be passed to another QSharedPointer object or deleted outside this object.
-
@Szymon-M-Sabat said in How QSharedPointer works?:
I think the docs could include your description.
It is - see https://doc.qt.io/qt-5/qsharedpointer.html#QSharedPointer-1 :
The pointer ptr becomes managed by this QSharedPointer and must not be passed to another QSharedPointer object or deleted outside this object.
@Christian-Ehrlicher said in How QSharedPointer works?:
The pointer ptr becomes managed by this QSharedPointer and must not be passed to another QSharedPointer object or deleted outside this object.
Yeah, now I get it but it wasn't obvious for me then, I was like "but I want to have many QSharedPointers" :(
