If foo() doesn't need to share ownership now but may need to later,
This doesn't make sense. Why would a function in a more narrow scope need to take or share ownership? The variable passed will persist before and after the function call.
The incorrect assumption that you came to is that we were talking about stack variables.
I don't know what this means here. I said scope, you are saying stack. If lifetime is being dictated purely by scope, you don't need shared_ptr, you can just use a unique_ptr at the correct scope.
But anyways, here's an example that's both scope-based and single threaded: std::vector<std::shared_ptr<bar> > v;
This isn't scope based lifetime, this is lifetime based on some other criteria than going out of scope. I will show you with what you wrote:
and another that duplicates and removes elements according to some ongoing criteria.
This doesn't make sense. Why would a function in a more narrow scope need to take or share ownership? The variable passed will persist before and after the function call.
The incorrect assumption that you came to is that we were talking about stack variables.
I don't know what this means here. I said scope, you are saying stack. If lifetime is being dictated purely by scope, you don't need shared_ptr, you can just use a unique_ptr at the correct scope.
But anyways, here's an example that's both scope-based and single threaded: std::vector<std::shared_ptr<bar> > v;
This isn't scope based lifetime, this is lifetime based on some other criteria than going out of scope. I will show you with what you wrote:
and another that duplicates and removes elements according to some ongoing criteria.