9

It's rather not a question "how to do it" it's rather "how to do it the right way"

I'm developing an editor in Qt where different widgets display the children and its (member) variables. Each of these widgets should hold a reference/pointer to the edited child to display and change their member variables.

The first attempt was the old ANSI C way I learned (and still kinda stuck in) with simple raw pointer to the used objects. It works fine but since the C++11 standard supports smart pointer and using them is recommended I'm trying to use them.

The problem is, I'm not quite sure what's the "best way" to use them in this case... After reading Smart Pointers: Or who owns you baby? and Which kind of pointer do I use when? and a few others I came to different conclusions:

The first is to use a*unique_ptr since the edited object is clearly the owner which creates and also deletes its children. The widgets are simply referring to the child to show or change them. The problem is how should the widgets refer to the child...

for now I'm simply still using a raw pointer I got with the get() method of the unique_ptr but this seems kinda flawed to me. I still can accidentaly call delete on the pointer and cancel the benefits of the smart pointer.

The second approach is to use a shared_ptr because many objects refer to the child and edit it. Also accidentaly deleting it in one widget would do no harm because it is still owned by other objects. The problem is they own it. When I want to delete it from the edited object I also have to signal all widgets to delete it before it is really gone. (this again seems flawed and error-prone)

I'm not really content with both ways. Is there a clean(er) way to point to the unique_ptr child of the object? Or am I missing a completely different and better approach to this problem?

Community
  • 1
  • 1
nils277
  • 231
  • 3
  • 8
  • Do you need the referencing objects to be alerted when the referenced object is destroyed? – Benjamin Lindley Aug 27 '13 at 01:39
  • 2
    In these kind of situations, we really need [dumb smart pointers](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3514.pdf). – Mark Garcia Aug 27 '13 at 01:43
  • @BenjaminLindley For now they need to be alerted to remove the corresponding widgets/controls and to not use them when deleted. e.g. one widget needs the get the coordinates of one child to place it in the OpenGL renderview. But i really try to avoid this because every widget needs to react to the signal emitted. It would be more ideal when the owner could determine itself whether a object still exists or not. – nils277 Aug 27 '13 at 01:48
  • 3
    "*I still can accidently call delete on the pointer*" You can only accidentally do that if you *call delete at all*. Simply banish *all* uses of `delete` in your code, then you can never "accidentally" use it ;) – Nicol Bolas Aug 27 '13 at 01:58
  • +1 to Nicol. You can accidentally `delete` a pointer you don't own. You can also accidentally `abort()`. Accidents are in the eye of the beholder. – Potatoswatter Aug 27 '13 at 02:10
  • The objects you use `unique_ptr` on, are they `QObject` subclasses? If yes, then be sure that they have no parent, and consider just using Qt parent-child mechanism instead of smart pointers, and consider using `QPointer` as a smart pointer to `QObject`. If they are not `QObject` subclasses, then using `std::` smart pointers is fine. – hyde Aug 27 '13 at 05:52

4 Answers4

3

Your use case doesn't translate directly to requirements (what if someone else deletes the widget while you're editing it?) but I'll assume you don't need anything beyond a naked pointer.

The Standard Library does not provide any strict pointer-observer class. Among observer entities:

  • Nullable, mutable pointers of native type (T *)
  • Non-nullable, non-mutable references of native type (T &)
  • Non-nullable, mutable references/proxies of class type (std::reference_wrapper<T>)
  • Nullable, self-validating, mutable pointers to managed objects (std::weak_ptr<T>)

If you want a non-nullable, mutable pointer to a non-managed object, which is a fairly reasonable thing to want, you can roll your own.

But naked pointers aren't that bad. The only difference is that it can be nullptr, and that it doesn't have a nice, long, explicit name inside namespace std.

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421
2

You want to use a shared_ptr in place of your unique_ptr and weak_ptr's in place of your raw pointers. This will give exactly what you're after. The weak_ptr's will not interfere with the edited object's ability to delete the underlying object.

Mark Garcia
  • 17,424
  • 4
  • 58
  • 94
Paul Evans
  • 27,315
  • 3
  • 37
  • 54
1

If you are using Qt, you might consider using the Qt smart pointers instead of std:: smart pointers:

or for QObjects:

  • QPointer (or QWeakPointer, esp in Qt4)

or to achieve copy-on-write data sharing, Qt container and QString style:

There are other pointer classes too, but some of the above are most likely to do what you want. Also important, if you have your data in Qt container classes, QStrings or such, they handle their own memory with copy-on-write semantics, and should generally be passed around as plain values (sometimes as references) instead of pointers.

But most importantly, do not use std::unique_ptr or std::shared_ptr with QObjects which have parents, because if the parent deletes the child first, then the std:: pointer will delete it again, crashing the program (other way will work ok, child will notify it's parent that it's deleted). In other words, there's a good chance of subtle bugs if you mix QObjects and std:: pointers, so just don't do it. It's not clear from your question if you are doing it, saying just in case.

hyde
  • 60,639
  • 21
  • 115
  • 176
  • You have a good point there. I didn't expect `QObject` to have a problem with the std::pointer. I think `QSharedPointer` and `QWeakPointer` are the way to go for me, since my objects derive from QObject to make use of signals and slots. – nils277 Aug 27 '13 at 14:19
  • @nill277 Note that same issue exists with `QSharedPointer`, it has no special support for `QObject` deleted by parent. If there is no parent object, then it's fine, but otherwise, same thing applies. I guess that's an ok way to do it, if your QObjects don't have any logical parent/owner, just be careful you remember to keep it that way (such as, don't have a constructor which allows giving parent). If they do have parent, then just use `QPointer` to hold weak references elsewhere. – hyde Aug 27 '13 at 14:31
0

There is a proposal for the world's dumbest smart pointer, which is a non-owning pointer. Basically, it is a T* that says "oh, and by the way, I don't claim any ownership over this data".

In this case, you have to manage that the observing/passive/dumb pointer gets reset if the unique_ptr goes away -- half manual lifetime management. Using a raw T* with a name that indicates it is non-owning works just as well prior to having the above.

There are benefits to doing the above, especially when you have objects with dependent lifetime.

If you do not, then a shared_ptr and weak_ptr works. Note, however, that anyone with a weak_ptr can create a new shared_ptr, which could extend the lifetime of the shared object beyond the original shared_ptr. This must happen, as there is otherwise a race condition whereby the user of the weak_ptr ensures its data is valid, then goes to use it, but before they do the shared_ptr's data is destroyed.

So the weak_ptr must either by able to prevent the shared_ptr from being destroyed (blocking in multi-threaded context, causing it to "fail" somehow in single-threaded contexts). "Fail" in this case consists of extending the lifetime, which solves both the multi-threaded and the single-threaded problem.

(The single threaded problem is that you verify the weak_ptr is good, do something that causes the shared_ptr to reset, then continue to want to use the weak_ptr's data without rechecking. Naively, it could be avoided with exceptions, but upon closer inspection you run into problems where you'd have to code all methods to check for deletion before accessing this and throw if this is deleted, a pretty harsh requirement!)

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524