On Mon, Apr 28, 2014 at 8:20 AM, Jeff Hill
I also find the nill state of shared_ptr to be a liability when designing interfaces. The primary purpose of shared_ptr when used in an interface context is to convey ownership, and almost always it feels wrong to also provide simultaneously an option to convey ownership of nothing. The poor user is left with the responsibility of testing every shared_ptr he has received for null state before using it, but its easy to forget and the compiler provides no assistance. Ultimately, the library interface based on shared_ptr is more error prone, less likely to be easy to use, and therefore arguably suboptimal.
Of course no one suggests that shared_ptr should (or could) be changed in ways that impacts backwards compatibility, but I have to agree with the author of the post that this issue can be identified as a legitimate cause for concern.
Jeff
There is usefullness to null and non-null smart pointers. Just so we're not repeating thoughts here too much, this was also discussed at the end of last year: http://lists.boost.org/Archives/boost/2013/10/206732.php I think the general consensus is that people want non-null smart pointers (myself included), but there are many subtleties that people disagree on. Be sure to read that thread going down paths that have been traveled before. -- -Matt Calabrese