Q:

Purpose of shared_ptr&& as constructor argument

This question extends a previous post discussing the usefulness of boost::shared<T>& as a constructor argument:  
class SomeClass {  
    SomeClass( const boost::shared_ptr<SomeOtherClass>& );  
} 

Would an rvalue reference argument in place of the boost::shared_ptr<T>& offer any advantage?  
class SomeClass {  
    SomeClass( const boost::shared_ptr<SomeOtherClass>&& );  
}    

In particular, for a multithreaded setting, would a constructor with an rvalue reference of shared_ptr type be any more useful then pass-by-value or pass-by-reference?

A:

shared_ptr isn't special.  The same rules apply to it as to pretty much any other object.  Would you ever make a const rvalue reference parameter?  I can't see any valid reason.  What about an rvalue reference of some other class?  Except in a class' own move constructor and move assignment operator, you should, for the most part, not take objects by rvalue reference.  If you need a copy of the object then you take it in by value, and move it, like this:
class SomeClass {
    std::shared_ptr<SomeOtherClass> myptr;
public:
    SomeClass(std::shared_ptr<SomeOtherClass> yourptr)
        :myptr(std::move(yourptr))
    {}
};

If you don't need a copy, then you take it in by const reference if your intent is just to examine it, or normal reference if you intend to modify it.
If you want to promise that you won't modify the object pointed to, then you can accept const std::shared_ptr<const SomeOtherClass> &, and that will work even if the argument doesn't have the inner const qualifier.

