问题
When a function takes a shared_ptr (from boost or C++11 STL), are you passing it:
by const reference:
void foo(const shared_ptr<T>& p)or by value:
void foo(shared_ptr<T> p)?
I would prefer the first method because I suspect it would be faster. But is this really worth it or are there any additional issues?
Could you please give the reasons for your choice or if the case, why you think it does not matter.
回答1:
This question has been discussed and answered by Scott, Andrei and Herb during Ask Us Anything session at C++ and Beyond 2011. Watch from 4:34 on shared_ptr performance and correctness.
Shortly, there is no reason to pass by value, unless the goal is to share ownership of an object (eg. between different data structures, or between different threads).
Unless you can move-optimise it as explained by Scott Meyers in the talk video linked above, but that is related to actual version of C++ you can use.
A major update to this discussion has happened during GoingNative 2012 conference's Interactive Panel: Ask Us Anything! which is worth watching, especially from 22:50.
回答2:
Here's Herb Sutter's take
Guideline: Don’t pass a smart pointer as a function parameter unless you want to use or manipulate the smart pointer itself, such as to share or transfer ownership.
Guideline: Express that a function will store and share ownership of a heap object using a by-value shared_ptr parameter.
Guideline: Use a non-const shared_ptr& parameter only to modify the shared_ptr. Use a const shared_ptr& as a parameter only if you’re not sure whether or not you’ll take a copy and share ownership; otherwise use widget* instead (or if not nullable, a widget&).
回答3:
Personally I would use a const reference. There is no need to increment the reference count just to decrement it again for the sake of a function call.
回答4:
Pass by const reference, it's faster. If you need to store it, say in some container, the ref. count will be auto-magically incremented by the copy operation.
回答5:
I ran the code below, once with foo taking the shared_ptr by const& and again with foo taking the shared_ptr by value.
void foo(const std::shared_ptr<int>& p)
{
static int x = 0;
*p = ++x;
}
int main()
{
auto p = std::make_shared<int>();
auto start = clock();
for (int i = 0; i < 10000000; ++i)
{
foo(p);
}
std::cout << "Took " << clock() - start << " ms" << std::endl;
}
Using VS2015, x86 release build, on my intel core 2 quad (2.4GHz) processor
const shared_ptr& - 10ms
shared_ptr - 281ms
The copy by value version was an order of magnitude slower.
If you are calling a function synchronously from the current thread, prefer the const& version.
回答6:
Since C++11 you should take it by value over const& more often than you might think.
If you are taking the std::shared_ptr (rather than the underlying type T), then you are doing so because you want to do something with it.
If you would like to copy it somewhere, it makes more sense to take it by copy, and std::move it internally, rather than taking it by const& and then later copying it. This is because you allow the caller the option to in turn std::move the shared_ptr when calling your function, thus saving yourself a set of increment and decrement operations. Or not. That is, the caller of the function can decide whether or not he needs the std::shared_ptr around after calling the function, and depending on whether or not move or not. This is not achievable if you pass by const&, and thus it is then preferably to take it by value.
Of course, if the caller both needs his shared_ptr around for longer (thus can not std::move it) and you don't want to create a plain copy in the function (say you want a weak pointer, or you only sometimes want to copy it, depending on some condition), then a const& might still be preferable.
For example, you should do
void enqueue(std::shared<T> t) m_internal_queue.enqueue(std::move(t));
over
void enqueue(std::shared<T> const& t) m_internal_queue.enqueue(t);
Because in this case you always create a copy internally
回答7:
Not knowing time cost of shared_copy copy operation where atomic increment and decrement is in, I suffered from much higher CPU usage problem. I never expected atomic increment and decrement may take so much cost.
Following my test result, int32 atomic increment and decrement takes 2 or 40 times than non-atomic increment and decrement. I got it on 3GHz Core i7 with Windows 8.1. The former result comes out when no contention occurs, the latter when high possibility of contention occurs. I keep in mind that atomic operations are at last hardware based lock. Lock is lock. Bad to performance when contention occurs.
Experiencing this, I always use byref(const shared_ptr&) than byval(shared_ptr).
回答8:
shared_ptr isn't large enough, nor do its constructor\destructor do enough work for there to be enough overhead from the copy to care about pass by reference vs pass by copy performance.
来源：https://stackoverflow.com/questions/3310737/should-we-pass-a-shared-ptr-by-reference-or-by-value