shared_ptr观察员20.8.2.2.5 C ++ 14最终草案（n4296）
long use_count() const noexcept;返回：
shared_ptr个对象的数量，包括*this，与*this共享所有权，或*this为空时为0。[注意：
use_count()不一定有效。 - 结束说明]
答案 0 :(得分：20)
根据这个页面
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html
签名的use_count的返回类型是为了避免诸如此类的陷阱 p.use_count（）＆gt; -1评估为假。
引用
John Lakos，大规模C ++软件设计，第9.2.2节，第637页，Addison-Wesley，1996年7月，ISBN 0-201-63362-0。
基本上，它看起来像是为新生软件开发人员量身打造的保姆级决策。
答案 1 :(得分：18)
原因是这种计数器最合适的类型是常规signed整数，即使此计数器永远不会低于0。
为什么计数器应为unsigned？鉴于语言unsigned的当前真实含义，它不能成为负面的事实根本不是一个有效的借口。
unsigned并不意味着一个不能为负的＆＃34;整数，＆＃34;。要理解为什么这个定义没有意义，请考虑
unsigned的差异为unsigned unsigned signed unsigned unsigned值永远不会大于-1 如果您认为unsigned表示＆＃34;非负面＆＃34;
对unsigned使用size_t是一个错误（例如参见Why is size_t unsigned?），只是部分*可原因的，因为在16位时代，一个额外的位被认为是值得错误的语义{C}中有unsigned种类型用于此类用途。
不幸的是现在size_t错误无法修复（因为向后兼容），但为什么在另一个不相关的区域重复同样的错误呢？
请注意，可能出现的最大错误就是选择名称unsigned（鉴于其真正含义）。如果该类型已被命名（更恰当地）modulo那么可能更明显的是，为什么使用modulo int来表示字符串的大小并没有任何意义。
名称无关紧要，重要的是语义，unsigned对于计数器或大小只有错误的语义。
（*）即便如此，我个人也不认为这是一个足够好的理由。如果32767现在还不够大，那么65535很快就不够了。在我看来，只有一点（价值的两倍）不是这种语义弯曲的可接受的价格。
我已发布了一个video，我在其中详细讨论了为什么我认为size_t的使用和无符号类型是C ++中的设计错误。