0

I’ve a question regarding the use of shared_ptr<...> over raw ptr. Consider the following example:

shared_ptr<BaseClass> someName = shares_ptr<Derived>(new Derived);
shared_ptr<BaseClass> someName1 = shares_ptr<Derived1>(new Derived1(someName));

Here, Derived1 takes an instance of shared_ptr<BaseClass> as input for it’s constructor. I use shared_ptr mainly for the purpose of polymorphism. Since one BaseClass instance can be used as input for multiple other Derived instance, unique_ptr is not an option because I have to change the ownership all the time.

But ownership is my main concern here. Derived instances doesn’t own the instances passed to the constructors. Is it better to pass a raw ptr?

Oblivion
  • 7,176
  • 2
  • 14
  • 33
Bastian
  • 1,553
  • 13
  • 33
  • "_shared_ptr<...> over raw ptr_" - is not the correct question. I'll probably get flak for this, but avoid `shared_ptr` too if you can. – Ted Lyngmo Aug 24 '19 at 05:24
  • Possible duplicate of [What is a smart pointer and when should I use one?](https://stackoverflow.com/questions/106508/what-is-a-smart-pointer-and-when-should-i-use-one) – walnut Aug 24 '19 at 05:25
  • also https://stackoverflow.com/questions/2454214/is-it-a-good-practice-to-always-use-smart-pointers – walnut Aug 24 '19 at 05:25
  • What would you say is it then? – Bastian Aug 24 '19 at 05:25
  • 1
    Raw vs. `unique_ptr` as @Oblivion says. `shared_ptr` has a totally different usecase - although I don't agree that you have a case using it. – Ted Lyngmo Aug 24 '19 at 05:26
  • "_I use shared_ptr mainly for the purpose of polymorphism_" - and still, a raw pointer will do the same. Use `unique_ptr` until some very special situation occurs. – Ted Lyngmo Aug 24 '19 at 05:32
  • ... and with the edit I agree with what @Oblivion answered. – Ted Lyngmo Aug 24 '19 at 05:34
  • 1
    @TedLyngmo I agree that, shared_ptr seems not to be good choice here. Thanks I edited my answer. – Oblivion Aug 24 '19 at 05:38
  • 1
    @Oblivion I must confess that I have yet to find a use for `shared_ptr` other than when patching. I'm perhaps biased but I would *never* put it in my design to start with. – Ted Lyngmo Aug 24 '19 at 05:43
  • 2
    @TedLyngmo I believe that's the right decision if one had maintainable software in mind. – Oblivion Aug 24 '19 at 05:56
  • See, I’ve a set of layers. You can think of it as a linked list. Where every node holds a pointer to the previous one. I’ve one special case where I don’t find another good solution: One layer instance needs the input of two previous layers. If I would use unique ptr here, I’d face problems with the ownership. Because every layer in the list must process it’s own input to produce an output which acts as input to the others. – Bastian Aug 24 '19 at 06:17
  • 1
    @Bastian Does what you describe have a `shared_ptr/weak_ptr` relationship by nature? If so - you are doing the right thing! – Ted Lyngmo Aug 24 '19 at 07:24
  • `unique_ptr is not an option because I have to change the ownership all the time.` with `unique_ptr` you can also change the ownership, you can always transfer the ownership from one `unique_ptr` to another, or even to a `shared_ptr`. – t.niese Aug 24 '19 at 08:25
  • `See, I've a set of layers. You can think of it as a linked list. [...] One layer instance needs the input of two previous layers.` It is hard to tell without knowing the code. But are you sure that reference to the previous layers is an owning reference? If you have tree structure the reference to the parent is also not owning but would be expressed as a raw pointer. – t.niese Aug 24 '19 at 08:31
  • It’s not really an ownership. It’s actually about using the data provided. A tree structure is almost the most precise description. But I actually thought that raw pointers shouldn’t be used and unique_ptr wouldn’t be a good approach so I used shared_ptr. But honestly, it looks quite ugly and the templates create boilerplate code. – Bastian Aug 24 '19 at 12:21

1 Answers1

1

If you need to manage ownership of a pointer, as a rule of thumb always prefer unique_ptr over raw pointer. And if you had a reason (i.e. if you share ownership, not transfering ownership with a single owner at a time) prefer shared_ptr over raw pointer.

If you need to use a pointer but not manage its lifetime use shared_ptr for management and weak_ptr for using the pointer without lifetime management.

Still you might find some use cases for raw pointer e.g. in helper functions which requires to be extra cautious to not to generate dangling pointers by accident.

Oblivion
  • 7,176
  • 2
  • 14
  • 33
  • 1
    `always prefer unique_ptr over raw pointer` that statement is very vague. Until `observer_ptr` are in the standard you still need raw pointers, whenever you need to pass an object but not the ownership (which would be the case for most helper functions to which you pass an object). Nowadays raw pointers should never be used to express/manager ownership. – t.niese Aug 24 '19 at 07:28