my understanding of the new memory <memory>header in C++11 is a bit week, but from what I can tell shared_ptr is refcounted ptr that makes it really really expensive to copy it(esp on for example ARM arch). And unique_ptr is pretty much the very very light wrapper around new/delete. And it is movable, so it is not like are limited by the scope where you created it.
So my question is:
is there a singlethreaded code usage where shared_ptr is prefered to unique_ptr?
Im not interested in answers like: making your singlethreaded code ready for future multithreading. Presume code is and will stay singlthreaded.
Your dwelling on threading here is kind of a red herring; there's a clear contrast between the two, and it has little to nothing to do with threads. If you're using these classes in a single-threaded environment, you may be able to turn off the atomic operations support; for example, with Boost, define the macro BOOST_SP_DISABLE_THREADS.
You use shared_ptr<> when you're not quite sure what the lifetime of an object will be, and want "the last guy in the room to shut off the lights" -- i.e., you don't want the object to be deleted until no client is using it any longer. You use unique_ptr<> when you know exactly who is going to delete the object -- i.e., when the lifetime of the pointed-to object is precisely delimitated by a scope.
It is true that copying a shared_ptr<> is not free, but it's far from "really, really expensive." You pay a little bit for the reference counting overhead, but that's the whole point of using it: you need to keep track of the clients of the object; there's a little cost involved, but you get the benefit of not leaking the object.