Smart pointers and parented QObjects

[yeye_olive]

We would like to combine the benefits of a smart pointer, we don't care which one(s), and parented QObjects with lifespans shorter than their parents. Specifically, if a parent QObject has a member smart pointer to a child, and that child may get destroyed and recreated several times through the parent's existence. It would be great to use a smart pointer for the child, as a developer wouldn't leak memory accidentally - at least for the duration of the life of the parent - if they failed to check the member's existence before creating a new instance.

(emphasis is mine)
Then you shouldn't use reference-counted smart pointers such as std::shared_ptr or QSharedPointer, because they precisely allow objects to escape a scope. The parent QObject is already managing the child's lifetime; everyone else can just manipulate a plain Child * pointer without worrying when to delete it (but must still be careful not to access the child after the parent has been destroyed).

I suggest one of those two options:

• store the pointer to the child in a plain Child * private member, and add a helper method void resetChild(Child *newChild) that deletes the existing child, if any (or calls deleteLater(), depending on your needs), before setting the new pointer. Explain to the developers that they must go through this method to set up a new child.
• if that is not enough (i.e. some developers keep modifying the Child * member directly), wrap the Child * in a smart pointer that forces updates to go through the method. std::unique_ptr (or QScopedPointer) do the trick, except that the parent's destructor must take care of calling unique_ptr::release() (or QScopedPointer::take()) to avoid double deletion. Or just implement a minimal ad hoc smart pointer yourself, which only initializes the Child * to NULL and forces updates to delete the existing child first.

[jason.gibbs@x-navtech.com]

Thank you all for your feedback. There were a few questions about why we would like to do this. Here's an example we ran across that prompted this discussion in our group. Suppose there is a dialog with the following properties:

1. it is complex and easier to construct from scratch when it is used than manage update/reset rules
2. it is modeless
3. we never want multiple instances of this dialog displayed

We want this dialog to be recreated whenever a particular slot in the parent is called and either deleted-on-closed or possibly deleted by a separate slot call.

Essentially this lead to our thinking that it would be fantastic if we could get all the benefits of the parent/child UI relationship without mandatory ownership by the parent. Some "emancipated minor" option to ask "hey, Parent- can you teach me where i fit in the UI world but not be in charge of my life after that?" A decoupling of object ownership and UI parenting benefits.

store the pointer to the child in a plain Child * private member, and add a helper method void resetChild(Child *newChild) that deletes the existing child, if any (or calls deleteLater(), depending on your needs), before setting the new pointer. Explain to the developers that they must go through this method to set up a new child.
if that is not enough (i.e. some developers keep modifying the Child * member directly), wrap the Child * in a smart pointer that forces updates to go through the method. std::unique_ptr (or QScopedPointer) do the trick, except that the parent's destructor must take care of calling unique_ptr::release() (or QScopedPointer::take()) to avoid double deletion. Or just implement a minimal ad hoc smart pointer yourself, which only initializes the Child * to NULL and forces updates to delete the existing child first.

Agreed - both are ways to accomplish this task. We were trying to find a way to use a more C++11(and beyond) approach to handling this situation - especially as we bring new developers into the fold. Our goal is to eliminate "delete" in our codebase if possible.

We really appreciate the time and effort put in to the replies. Thank you so much!

[d_stranz]

1. it is complex and easier to construct from scratch when it is used than manage update/reset rules
2. it is modeless
3. we never want multiple instances of this dialog displayed

1. This is puzzling. Whatever you do upon construction could be factored into an initialization method called from the constructor or a reset() method.
2. That just makes it a little awkward to use a stack-based instance to control lifetime
3. So what happens if the dialog already is on display? Does executing the action that invokes it do nothing, thus causing the user to try to execute it again in frustration? Does the existing dialog get moved to the top with whatever contents it currently contains, thus confusing the user? Does the existing dialog vanish only to get replaced with a clean new version, thus annoying the user who was editing or observing something when the action invoking the new dialog was executed from behind the scenes somehow?

To me, this says that you are trying to wrap smart pointer functionality around something that should instead be controlled by business logic. The business logic should determine that the action(s) which can invoke the dialog must be disabled if the dialog is already in existence. If your developers are too undisciplined to abide by the business rules, then code review and testing will uncover the violation.

You could implement your dialog as a singleton with a private constructor and an instance() method. That could ensure that only one is in existence, but it wouldn't help with the issues I raised in (3) above. It would help with the update/reset issue, but only if your singleton was constructed in a way that deleted the instance upon closure of the dialog.