【问题标题】:When explicitly initializing std::optional's, should I use nullopt? [closed]当显式初始化 std::optional 时,我应该使用 nullopt 吗? [关闭]
【发布时间】:2016-10-14 09:10:47
【问题描述】:

std::optional<T> 可以像这样初始化为分离状态:

std::optional<int> oi { nullopt };

但也像这样:

std::optional<int> oi { };

同样适用于分配(oi = {}oi = nullopt)。

除了个人喜好/审美感之外,这些之间是否有区别让我更喜欢其中一个?还是根本不重要?

注意:我问的是我想显式初始化可选的情况,而不是默认初始化它(例如为了强调)。

【问题讨论】:

  • 到目前为止,你是如何初始化你的空闲 std::functions 和 std::shared_ptrs 和 std::unique_ptrs 的?
  • 也可以这样初始化:std::optional&lt;int&gt; oi;,如果我可以选择的话,这可能是我会使用的版本。
  • @juanchopanza:还有std::optional&lt;int&gt; oi = nullopt;,如果你不是大括号中的一员,但仍然想明确表达。 (哈:“显式”,但不是explicit :-)。)
  • @juanchopanza:我认为“总是自动”的人群与“到处都是大括号”的人群大致相同:-)
  • 它似乎确实对性能有影响(取决于实现)。见this question

标签: c++ optional c++17 idioms


【解决方案1】:

这根本不重要。选择任何能让你的同事更好地理解你的代码的东西。

【讨论】:

  • 那么,可能是nullopt,因为大脑在计算这一点时所付出的努力少了一点,而不是“嗯,如果我使用空括号会发生什么”?
  • @einpoklum:是的,但请注意您使用的是错误的二分法。问题下的 cmets 指出了几个进一步的选择,你们都应该相互权衡。 (就个人而言,我会使用默认初始化或“= nullopt;”。)
  • @einpoklum 作为一个意见问题,我发现使用{} 来表示“meh, nothing there”(如空集)在我的现代 C++ 代码中是一个非常强大的习语。它在返回许多可能为空的东西时起作用,例如容器、可选项或 std 函数。 nullopt 的细节无关紧要。在其他情况下,需要一个实际的 nullopt(例如,?:)。
【解决方案2】:

它们都具有相同的效果 - 我更喜欢最简单的形式(KISS),但它是主观的,选择一个并保持一致。您可能还希望与您在代码中对待其他对象的方式保持一致,您通常是否依赖默认初始化(例如int i{} vs int i{0})?

就我个人而言,当我看到冗余代码时,例如明确地将对象初始化为其默认值,它确实会稍微降低我对作者的信心 - 作者是否真的了解他在做什么并试图更加安全/明确/ 可读,或者他只是懒得阅读文档?这让我想知道,作者是否理解当他写std::vector&lt;std::optional&gt; v(n)或更复杂的例子时会发生什么?如果这是一个记录在案的决定,采用编码风格,那么一切都很好,我可以理解提高可读性的必要性。

【讨论】:

  • 我非常依赖默认初始化,但我经常区分“我不在乎值是什么”和“我希望您注意我默认设置此值”。特别是如果我有几个字段 - 有些我可能会默认初始化,而另一些我会显式初始化为某个值(这可能只是默认值)。
猜你喜欢
  • 2020-11-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-04-20
  • 2015-02-24
  • 2018-04-07
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多