- initial copy-construction expensive for large Obj
+ easy memory: when out of scope, goes away
+ more explicit/self-contained in terms of ownership
+ read a bit faster since no indirection needed
- may require a default constructor
map< string, Obj* >
+ insertion/copying is cheap: only a pointer
- have to think about ownership issues for new/delete
+ more flexible: actual Obj can live else-where
- requires extra indirection
+ can take-advantage of memory pools if you create a gazillion Obj (requires new)
unique_ptr is... somewhat thread-safe, because of its "uniqueness". Unfortunately, there is a way to get around it...
Something you would need to watch out for is that std::unique_ptr is a C++0x feature, so... be sure you use the appropriate compiler and flags. ;) Also, if you're relying on the unique_ properties of a unique_ptr, do note that there are ways to accidentally (or deliberately) circumvent these properties, such as unique_ptr::get().
[It] stores a pointer to an owned object. The object is owned by no other unique_ptr.
Finally, I don't know how valgrind works with unique_ptr. Sorry. :(