C++ 为什么boost可选引用不是T*的包装器？

既然

boost:：optional

已经是一种专业化，为什么它不作为

t*

的包装器来实现呢？这将允许它占用更少的空间，因为不需要使用

m_initialized

布尔值。

可能是因为未初始化的

boost:：optional

对象必须与使用

NULL

初始化的

boost:：optional

对象不同，例如，此函数不能返回任何值，

NULL

或非

NULL

指针

---

在这种情况下，为什么不使用一个普通指针，

NULL

表示没有值呢。使用

boost:：optional

，无需再增加复杂性。我的意思是，让事情变得更大或更复杂很容易，但很难让它们变得更好。

首先，

boost:：optional

不是一种专门化。如果您查看代码，您将看到它确实执行了一些基于标记的分派来定制引用类型的行为，但是

boost:：optional_base

类模板本身并没有专门化

然而，为什么不实施这种空间优化仍然是一个合理的问题。可能是因为它不是专门的，我不知道这工作有那么难

关于为什么您更喜欢

optional

而不是原始指针的问题是一个完全独立的问题，所以请随意单独提问…

，因为optional在引用的情况下是优化的

发行说明提到：

sizeof(optional<T&>) == sizeof(T*)

sizeof（可选）=sizeof（T*）

---

因此，在这种情况下，它肯定是作为指针实现的。

请告诉我指针的大小要求是8字节或任何其他大小。好吧，这不仅仅是空间不足！这是关于复制这些东西的费用，以及缓存性能。另外，我并不是因为某一段特定的代码而问这个问题，我更感兴趣的是

T*

vs.

boost:：optional

。再说一次-在性能成为问题之前不要操心-让编译器优化它-程序员最不擅长优化自己的代码。我在一个微秒很重要的环境中工作——我们忽略所有这些东西，直到它成为一个问题——我不会为此而流汗。出于安全考虑，我已经选择了

boost:：optional

。然而，在解释这种偏好时，最好能说它是C++零开销原则优化后的一个很好的例子。我不明白为什么它会以这种方式实现，我想这是一个很好的理由，这对我和堆栈溢出社区来说是一个很好的知识。如果你不知道，别躲在那后面，把我的兴趣当作非法的。我从来没有说过任何话来表明我过早地进行了优化。实际上，在我的版本（1.48）中，没有专门的

可选
供参考。相反，许多内部类专门用于引用。特别是，保存实际值的类型是
typedef:：boost:：detail:：make_reference\u content:：type internal_type
，专门用于引用。他没有给你一个你应该解决的问题，他问了一个关于boost:：optional的问题。他可能有很好或很坏的理由使用它，但这超出了问题的范围。我想你可能误解了。。。我看不出你的答案与
boost:：optionals
+1有什么关系。为了mozza314等人的利益，您可以补充说，还没有人有时间或意愿（目前）优化引用的情况，因此它只使用最高级别的一般实现。但是，不管怎么说，立方体的评论，你不应该考虑OP的真正问题可能是最好忽略：你做的完全正确，imo，我同意这个建议。如果你认为这个答案是正确的，也许你可以启发我，因为它听起来像一个总的红色鲱鱼给我。code>optional
而未初始化的可选值与存储空指针之间的差异完全无关。我询问了
可选的
，您可能知道引用不能为空。同意，这并不能回答问题。问题是关于
可选的
，这个答案是关于
可选的
。