什么是boost::optional efficiency？

Question

我有以下几点：

class Obj;
typedef std::map<string, string> StrMap;
std::map<std::string, std::pair<Obj, StrMap> > complexMap;

问题是，对于boost中的某些条目，StrMap将是空的，我根本不会使用它，所以为了提高效率，我正在考虑使用boost::optional。我的问题是，boost::optional的效率是什么，我担心通过付出代价，我最终将一无所获。

Answer 1

可以将optional看作一个可以容纳0或1值的容器。您的map已经是一个可以容纳0到N个元素的容器。因此，一个可选的map是一个容器中的容器，它可以容纳0到N个元素。真的，这里没有任何好处。

空映射的开销非常小。地图实际上是由地图节点构建的，在内部，一个空的地图没有任何节点。(它不能，因为每个节点都有一个值，并且空的map无法创建默认值)

Answer 2

如果你在做“稀疏”计算，你可以做两件事：

1. 保留了一个很大的complexMap，其中包含大量不存在的boost::optional结果。这封装了基于per-element的稀疏性。
2. 创建了额外的间接层(例如unordered_map)。它包含指向complexmMap中现有元素的指针。这将在每个地图的基础上封装稀疏性。

对于程序员来说，备选方案1会更方便，虽然以空间开销为代价，但只需要很少的空间。备选方案2将几乎完全节省空间，并使complexMap尽可能小，但需要预先进行更多的编程工作。

选择您更容易接受的替代方案(提示:如果您在complexMap中进行千兆字节级别的计算，可能额外的间接级别会得到回报，否则我不会费心)。

除了空间开销，boost::optional几乎没有其他开销，因为它不需要默认构造函数或动态内存分配。

Answer 3

正在将评论移动到答案...

想想optional是如何实现的，它通常有一些内部存储(允许它保存地图对象-就像你在上面的代码中所做的那样)，唯一的区别是它不会在该存储中构造地图-这将留到以后。但是，必须构造可选对象。因此，现在不是仅仅构造一个map，而是在不使用map的情况下构造一个更大的可选对象，当您使用map时，您也必须构造它。看起来你做了更多的事情却没有什么好处。

在某些情况下，optional确实有意义(例如，返回值，例如，您想要指示无效的状态，或者您有一个非常昂贵的构造函数来执行大量复杂成员的初始化)，对于具有简单构造函数的对象，optional真的不值得代码混乱。

免责声明:但与所有与性能相关的问题一样，配置文件，配置文件，然后再次配置文件...