Temporary object argument lifetime in a function - c++

Question

I've read several posts about temporary object's lifetime. And in a word I learn that:
the temporary is destroyed after the end of the full-expression
containing
it.
But this code is out of my expectation:
#include <memory>
#include <iostream>
void fun(std::shared_ptr<int> sp)
{
std::cout << "fun: sp.use_count() == " << sp.use_count() << '\n';
//I expect to get 2 not 1
}
int main()
{
fun(std::make_shared<int>(5));
}
So I think I have 2 smart pointer objects here, one is std::make_shared<int>(5), the temporary unnamed object and the other sp which is a local variable inside the function. So based on my understanding, the temporary one won't "die" before completing the function call. I expect output to be 2 not 1. What's wrong here?

Answer 1

Pre-C++17, sp is move-constructed from the temporary if the move is not elided to begin with. In either case, sp is the sole owner of the resource, so the use count is rightly reported as 1. This is overload 10)† in this reference.
While the temporary still exists, if not elided, it is in a moved-from state and no longer holds any resource, so it doesn't contribute to the resource's use count.
Since C++17, no temporary is created thanks to guaranteed copy/move elision, and sp is constructed in place.
† Exact wording from said reference:
10) Move-constructs a shared_ptr from r. After the construction, *this contains a copy of the previous state of r, r is empty and its stored pointer is null. [...]
In our case, r refers to the temporary and *this to sp.

Answer 2

c++ has a strange concept known as elision.
Elision is a process whereby the compiler is allowed to take the lifetime of two objects and merge them. Typically people say that the copy or move constructor "is elided", but what is really elided is the identity of two seemingly distinct objects.
As a rule of thumb, when an anonymous temporary object is used to directly construct another object, their lifetimes can be elided together. So:
A a = A{}; // A{} is elided with a
void f(A);
f(A{}); // temporary A{} is elided with argument of f
A g();
f(g()); // return value of g is elided with argument of f
There are also situations where named variables can be elided with return values, and more than two objects can be elided together:
A g() {
A a;
return a; // a is elided with return value of g
}
A f() {
A x = g(); // x is elided with return value of g
// which is elided with a within g
return x; // and is then elided with return value of f
}
A bob = f(); // and then elided with bob.
Only one instance of A exists in the above code; it just has many names.
In c++17 things go even further. Prior to that the objects in question had to logically be copyable/movable, and elision simply eliminated calls the the constructor and shared the objects identity.
After c++17 some things that used to be elision are (in some sense) "guaranteed elision", which is really a different thing. "Guaranteed elision" is basically the idea that prvalues (things that used to be temporaries in pre-c++17) are now abstract instructions on how to create an object.
In certain circumstances temporaries are instantiated from them, but in others they are just used to construct some other object in some other spot.
So in c++17 you should think of this function:
A f();
as a function that returns instructions on how to create a A. When you do this:
A a = f();
you are saying "use the instructions that f returns to construct an A named a".
Similarly, A{} is no longer a temporary but instructions no how to create an A. If you put it on a line by itself those instructions are used to create a temporary, but in most contexts no temporary logically or actually exists.
template<class T, class...Us>
std::shared_ptr<T> make_shared(Us&&...);
this is a function that returns instructions on how to create a shared_ptr<T>.
fun(std::make_shared<int>(5));
here you apply these instructions to the agument of fun, which is of type std::shared_ptr<int>.
In pre-[C++17] without hostile compiler flags, the result with elision is practically the same here. In that case, the temporaries identity is merged with the argument of fun.
In no practical case will there be a temporary shared_ptr with a reference count of 0; other answers which claim this are wrong. The one way where that can occur is if you pass in flags that your compiler from performing elision (the above hostile compiler flags).
If you do pass in such flags, the shared_ptr is moved-from into the argument of fun, and it exists with a reference count of 0. So use_count will remain 0.

Answer 3

In addition to the move construction of std::shared_ptr, there is another aspect to consider: in-place creation of function argument passed by value. This is an optimization that compilers usually do. Consider the exemplary type
struct A {
A() { std::cout << "ctor\n"; }
A(const A&) { std::cout << "copy ctor\n"; }
};
together with a function that takes an instance of A by value
void f(A) {}
When the function parameter is passed as an rvalue like this
f(A{});
the copy constructor won't be called unless you explicitly compile with -fno-elide-constructors. In C++17, you can even delete the copy constructor
A(const A&) = delete;
because the copy elision is guaranteed. With this in mind: the temporary object that you pass as a function argument is "destroyed after the end of the full-expression containing it" only if there is a temporary, and a code snippet might suggest the existence of one even though it's easily (and since C++17: guaranteed to be) optimized out.