9

的推理std::optional是说它可能包含也可能不包含值。因此，如果我们不需要它，它就节省了我们构建一个可能是大对象的工作。

例如，如果不满足某些条件，这里的工厂将不会构造对象：

#include <string>
#include <iostream>
#include <optional>

std::optional<std::string> create(bool b) 
{
    if(b)
        return "Godzilla"; //string is constructed
    else
        return {}; //no construction of the string required
}

但是，这与此有何不同：

std::shared_ptr<std::string> create(bool b) 
{
    if(b)
        return std::make_shared<std::string>("Godzilla"); //string is constructed
    else
        return nullptr; //no construction of the string required
}

我们通过在一般情况下添加std::optional而不是使用来赢得std::shared_ptr什么？

4

5 回答 5

17

我们通过添加 std::optional 而不是通常使用 std::shared_ptr 赢得了什么？

假设您需要从带有“非值”标志的函数中返回一个符号。如果您使用std::shared_ptr它，您将有巨大的开销 -char将在动态内存中分配，std::shared_ptr并且会维护控制块。而std::optional在另一边：

如果一个可选项包含一个值，则保证该值作为可选对象占用空间的一部分进行分配，即不会发生动态内存分配。因此，即使定义了 operator*() 和 operator->()，可选对象也建模对象，而不是指针。

因此不涉及动态内存分配，即使与原始指针相比，差异也可能很大。

于 2017-03-21T14:35:43.473 回答
7

可选项是可为空的值类型。

Ashared_ptr是可以为空的引用计数引用类型。

Aunique_ptr是可以为空的仅移动引用类型。

它们的共同点是它们可以为空——它们可以“不存在”。

它们是不同的，其中两个是引用类型，另一个是值类型。

值类型有几个优点。首先，它不需要在堆上分配——它可以与其他数据一起存储。这消除了可能的异常源（内存分配失败），可以更快（堆比堆栈慢），并且对缓存更友好（因为堆往往相对随机排列）。

引用类型还有其他优点。移动引用类型不需要移动源数据。

对于非仅移动引用类型，您可以使用不同名称对相同数据进行多个引用。具有不同名称的两种不同值类型总是引用不同的数据。无论哪种方式，这都可能是优势或劣势；但它确实使对值类型的推理变得更加容易。

推理shared_ptr是非常困难的。除非对数据的使用方式进行一套非常严格的控制，否则几乎不可能知道数据的生命周期。推理unique_ptr要容易得多，因为您只需要跟踪它的移动位置。关于 ' 生命周期的推理optional是微不足道的（嗯，就像你嵌入它一样微不足道）。

可选接口增加了一些类似单子的方法（如.value_or），但这些方法通常可以很容易地添加到任何可为空的类型中。不过，目前，它们是为了optional而不是为了shared_ptror unique_ptr。

optional 的另一个大好处是，您非常清楚您有时希望它可以为空。C++ 中有一个坏习惯是假定指针和智能指针不为空，因为它们的使用不是可空的。

因此代码假定某些共享或唯一的 ptr 永远不会为空。它通常有效。

相比之下，如果你有一个可选的，你拥有它的唯一原因是因为它有可能实际上是空的。

在实践中，我对将 aunique_ptr<enum_flags> = nullptr作为参数持怀疑态度，我想说“这些标志是可选的”，因为在调用者身上强制进行堆分配似乎很粗鲁。但是 anoptional<enum_flags>不会强制调用者这样做。非常便宜的optional特性让我愿意在很多情况下使用它，如果我唯一的可空类型是智能指针，我会找到一些其他的解决方法。

这消除了“标志值”的大部分诱惑，例如int rows=-1;. optional<int> rows;具有更清晰的含义，并且在调试中会告诉我何时使用行而不检查“空”状态。

可以合理失败或不返回任何感兴趣的函数可以避免标志值或堆分配，并返回optional<R>。例如，假设我有一个可放弃的线程池（例如，当用户关闭应用程序时停止处理的线程池）。

我可以std::future<R>从“队列任务”函数返回并使用异常来指示线程池已被放弃。但这意味着线程池的所有使用都必须针对“来自”异常代码流进行审核。

相反，我可以 return std::future<optional<R>>，并向用户提示他们必须在他们的逻辑中处理“如果该过程从未发生过会发生什么”。

“来自”异常仍然可能发生，但它们现在是异常的，不是标准关闭程序的一部分。

在其中一些情况下，expected<T,E>一旦它在标准中，将是一个更好的解决方案。

于 2017-03-22T13:36:06.747 回答
4

指针可能为NULL，也可能不是。这对你来说是否意味着什么完全取决于你。在某些情况下，nullptr它是您处理的有效值，而在其他情况下，它可以用作指示“没有值，继续前进”的标志。

有了std::optional，就有了“包含值”和“不包含值”的明确定义。您甚至可以使用带有可选的指针类型！

这是一个人为的例子：

我有一个名为 的类Person，我想从磁盘延迟加载它们的数据。我需要指出是否已加载某些数据。让我们为此使用一个指针：

class Person
{
   mutable std::unique_ptr<std::string> name;
   size_t uuid;
public:
   Person(size_t _uuid) : uuid(_uuid){}
   std::string GetName() const
   {
      if (!name)
         name = PersonLoader::LoadName(uuid); // magic PersonLoader class knows how to read this person's name from disk
      if (!name)
         return "";
      return *name;
   }
};

太好了，我可以使用该nullptr值来判断名称是否已从磁盘加载。

但是如果一个字段是可选的呢？也就是说，PersonLoader::LoadName()可能会nullptr为这个人返回。每次有人请求这个名字时，我们真的想去磁盘吗？

输入std::optional。现在我们可以跟踪我们是否已经尝试加载名称以及该名称是否为空。如果没有std::optional，解决方案是isLoaded为名称以及每个可选字段创建一个布尔值。（如果我们“只是将标志封装到一个结构中”呢？好吧，那么你已经实现optional了 ，但做得更糟）：

class Person
{
   mutable std::optional<std::unique_ptr<std::string>> name;
   size_t uuid;
public:
   Person(size_t _uuid) : uuid(_uuid){}
   std::string GetName() const
   {
      if (!name){ // need to load name from disk
         name = PersonLoader::LoadName(uuid);
      }
      // else name's already been loaded, retrieve cached value
      if (!name.value())
         return "";
      return *name.value();
   }
};

现在我们不需要每次都去磁盘了；std::optional允许我们检查。我在评论中写了一个小例子，以较小的规模展示了这个概念

于 2017-03-21T14:28:15.277 回答
3

重要的是，如果您尝试从一个不存在的可选项访问它，您将得到一个已知的、可捕获的异常而不是未定义的行为value()。因此，如果出现问题，optional您可能会比使用shared_ptr或类似的情况有更好的调试时间。（请注意，在这种情况下，*取消引用运算符optional仍然给出 UB；使用value()是更安全的选择）。

此外，诸如 之类的方法通常很方便value_or，它允许您很容易地指定“默认”值。相比：

(t == nullptr) ? "default" : *t

和

t.value_or("default")

后者更具可读性且略短。

最后，一个项目的存储optional在对象内。这意味着optional如果对象不存在，则 an 需要比指针更多的存储空间；但是，这也意味着不需要动态分配将对象放入空的optional.

于 2017-03-21T14:39:02.953 回答
0

我们通过添加 std::optional 而不是通常使用 std::shared_ptr 赢得了什么？

@Slava 提到了不执行内存分配的优势，但这是一个附带好处（好吧，在某些情况下它可能是一个显着的好处，但我的观点是，它不是主要的）。

主要好处是（恕我直言）更清晰的语义：

返回指针通常意味着（在现代 C++ 中）“分配内存”，或“处理内存”，或“知道这个和那个的内存地址”。

返回一个可选值意味着“没有这个计算的结果，不是错误”：返回类型的名称告诉你 API 是如何构思的（API 的意图，而不是实现）。

理想情况下，如果您的 API 不分配内存，则不应返回指针。

在标准中提供可选类型，确保您可以编写更具表现力的 API。

于 2017-03-21T15:24:18.127 回答