I think 5.b is mostly applicable when you're packaging DLLs. I don't see much use for it in internal projects (Eg. If I'm building a end user solution and not developer solution).

Yes - it's mostly applicable when you're creating APIs and developer solutions. But even in case of internal tools/ exes, you might need to share functionality with a internal partner team and it's helpful if they don't have to read code they don't need to use.

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

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

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.

You can do const shared_ptr<const type>, it's like a const * const raw pointer.

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-poi...

If you're going to pass it by const_ref, why not just pass the actual stored object by const_ref instead?

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_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.

> 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?

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.

You are correct. I had a brain fart. Edited my comment.

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.

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.

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.

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.