5 ms·

Interesting point about shared_ptr. Do you think shared_ptrs should be passed by const reference or just reference ?

• corysama 10y ago
  I'm a "const all the things!" coder in general. If you see something that's not const, that is documentation that you should expect your object to be modified, not that I was too lazy to type 'const' ;P
  • millstone 10y ago
    Unfortunately a const shared_ptr is like a const raw pointer: you can't change the pointer itself, but can still modify what it points to.
    • Too 10y ago
      You can do const shared_ptr<const type>, it's like a const * const raw pointer.
• sharth 10y ago
  If you're going to pass it by const_ref, why not just pass the actual stored object by const_ref instead?
  • corysama 10y ago
    Edit: Ignore this comment. I shouldn't talk so much about something I use so little. Somehow I skimmed through http://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr http://en.cppreference.com/w/cpp/memory/shared_ptr/shared_pt... and thought that shared_ptr( const shared_ptr& r ); was missing. >> That's a good point. If the function will eventually lead to some object retaining a reference, then you should use a non-const shared_ptr ref. The assignment into the object will do the copy constructor and that needs a non-const ref. But, you don't need to be making temp object copies along the way. If the function will not lead to something retaining a reference, then you shouldn't be passing the reference retention object to it. Just pass a direct ref to the target object.
    • tomjakubowski 10y ago
      > The assignment into the object will do the copy constructor and that needs a non-const ref. Hum? What assignment into the object? Where I'd typically see taking a `const std::shared_ptr<> &` to signal "retaining ownership" would be something like this: class Foo { public: void AppendChild(const std::shared_ptr<Foo> &x) { children_.emplace_back(x); } private: std::vector<std::shared_ptr<Foo>> children_; }; Why should Foo:;AppendChild's signature be changed to a non-const ref?
      • corysama 10y ago
        You are correct. I had a brain fart. Edited my comment.
      • millstone 10y ago
        It should be changed to pass by value, and then use std::move to move it into the children array. The reason is that if the argument is a temporary, you are making an unnecessary copy of that temporary, when you could just transfer ownership. This also gives callers the flexibility to std::move into your argument, transferring ownership. A good rule of thumb is, if you are going to unconditionally take ownership of an object, accept it by value.
• optforfon 10y ago
  Typically you should pass raw pointers (constness depends on your use case...). I can't really think of a scenario where the method/function needs to be coupled with the pointer type.
  • MereInterest 10y ago
    I will often have functions that accept a unique_ptr as a parameter. This way, I can clearly encode that the object belongs to the callee now.
  • zanny 10y ago
    And if you are wanting to pass the raw pointer, you should probably pass by & instead as well. The only real "features" of raw pointers over references are the ability to reassign or delete them, and if you are passing something by reference, you do not want anyone doing any such thing to it 99.9% of the time.
• Kristine1975 10y ago
  Unless they are modified: const reference. Otherwise you cannot pass a temporary object as in: void foo(const std::shared_ptr<int>& p); ... foo(std::make_shared<int>(23)); This will not compile with void foo(std::shared_ptr<int>& p); since a temporary object cannot be implicitly converted to a non-const reference, only to a const one.
• pveierland 10y ago
  Herb Sutter's GotW #91 talks about smart pointer parameters in detail and when to use const and reference: https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/ https://herbsutter.com/2013/06/05/gotw-91-solution-smart-poi...