为什么shared_ptr <T> :: use_count()返回long而不是unsigned类型？

Question

shared_ptr观察者20.8.2.2.5 C++ 14最终草案(n4296)

   long use_count() const noexcept;

返回:共享所有权的shared_ptr对象数,或者为空时为0 .*this*this*this

[注意:use_count()效率不一定. - 结束说明]

Answer 1

根据这个页面

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html

对use_count的返回类型进行了签名,以避免陷入诸如p.use_count()> -1评估为false的陷阱.

参考

John Lakos,大规模C++软件设计,第9.2.2节,第637页,Addison-Wesley,1996年7月,ISBN 0-201-63362-0.

基本上,它看起来像是为新生软件开发人员量身打造的保姆级决策.

Answer 2

原因是这种计数器最合适的类型是一个常规signed整数,即使这个计数器永远不会低于0.

为什么一个柜台应该是unsigned？这不能成为否定的事实是不是在所有给定电流的有效借口真正意义上的unsigned的语言.

unsigned对于C++而言,并不意味着"不能为负数的整数".要理解为什么这个定义根本没有意义

• 两者的区别unsigned是unsigned
• 添加unsigned一个signed是unsigned
• 一个unsigned值永远不会比大-1

如果你认为unsigned意思是"非负面" ,则上述任何一个都没有任何意义.

使用unsignedfor size_t是一个错误(参见例如为什么size_t无符号？),只是部分*可原因的,因为在16位时代,一个额外的位被认为是值得错误的语义,unsigned类型在C++中用于这种用途.

不幸的是现在size_t错误无法修复(因为向后兼容),但为什么在另一个不相关的区域重复同样的错误呢？

请注意,可能最大的错误就是选择名称unsigned(鉴于它的真正含义).如果这个类型已被命名(更合适),modulo那么为什么使用a modulo int作为字符串的大小根本没有任何意义可能会更明显.

这个名字是无关紧要的,重要的是语义,unsigned对于一个计数器或一个大小,它只是有错误的语义.

(*)即使在那时,我个人也认为这不是一个足够好的理由.如果现在32767对于一个大小来说还不够,那么65535真的不会很快.在我看来,只有一点(价值的两倍)不是这种语义弯曲的可接受的价格.

编辑

我已经发布了一个视频,我正在讨论更多细节,为什么我认为使用和无符号类型size_t是C++中的设计错误.

幻灯片可以从http://raksy.dyndns.org/unsigned.pdf下载