为什么返回类型的AddRef（）和Release（）不是HRESULT

Question

最近开始学习COM。在COM中，返回类型的函数应该是HRESULT。已阅读HRESULT，GetLastError()的问题，但为什么，IUnknown的函数，AddRef()和Release()返回类型为ULONG？

我已经得出AddRef()（几乎）始终从QueryInterface()调用的答案，而客户端不应该调用它。对于Release()，永远不会检查其返回值。

虽然我可以用以下方式争辩自己的答案 - 对于AddRef() - 客户可能需要调用它。并且由于客户端可以访问该功能，因此客户端不会调用它的保证是什么。

for Release() - 再次，用户可以检查其返回类型，因为他可以

请澄清。

也是如此 - ＆gt;它的约定是为COM相关函数而不是强制的HRESULT返回类型 - ＆gt;如果这是真的，它将阻止我脑中的混乱。

Answer 1

  

＆＃34; AddRef和Release无法失败，所以没有任何意义   返回HRESULT。＆＃34; -Igor Tandetnik

我发布这个作为答案只是因为我的眼睛因为阅读整个问题以及希望帮助某人的所有评论而流泪......来到SO社区，让我们关闭这些类型的问题。如果没有所有这些垃圾的筛选，人们会更容易帮助。

Answer 2

我问自己一个类似的问题：为什么我们在界面中需要3个方法而不是2个？ QueryInterface和Release应该足够了。 QI已经做了AddRef，理论上我们有两种方法用来做同样的工作，其中一种应该被淘汰。 QI做的还有AddRef。 AddRef只做AddRef。 AddRef死了。 KISS。

现在对于返回类型，我不同意AddRef / Release不会失败的评论。好吧，他们可以。以几种不同的方式，它们应该遵循相同的HRESULT返回规则并产生参数。

AddRef失败的一种方法是你可以超过ULONG_MAX（难以实现，但可能）。或者用于使该调用线程安全的信号量可以抛出异常。这么多事情实际上可能会出错，因为我可以想象规范只有ULONG（void）的唯一原因就是性能，因为调用没有参数的方法要容易得多。

客户端性能在90年代已经成为现实，它绝对不再是一件事（除非你在谈论受限制的客户端，比如移动设备）。通过以性能的名义牺牲语义，COM设计实际上造成了维护的长期负担，而牺牲了每个人都知道并且知道总是消失的性能的短期收益（摩尔定律，容量每18倍增加一倍）几个月的成本相同）。

但即便如此，AddRef并不是你应该如此频繁地调用的东西。这样做意味着你在系统的几个部分周围携带相同的物体，这本身就是一个糟糕设计的强烈指示。

我也不同意这是一个不好的问题。这是一个很好的问题，因为它让人们思考。因此，人们会遇到困难，所以要回答具体问题。然而，让人们思考广泛/开放式问题会教会他们技能，以防止他们陷入困境。