我们应该在任何地方使用constexpr吗？

Question

我们显然无法做出所有事情constexpr。如果我们不做任何事情constexpr，那么就不会有任何大问题。到目前为止，很多代码都没有编写。

但在任何可能拥有它的东西中拍打constexpr是一个好主意吗？这有什么潜在的问题吗？

Answer 1

它不会打扰编译器。如果您在不符合constexpr要求的代码上使用它，编译器将（或者无论如何）给您诊断。

与此同时，我有点犹豫，因为你可以在那里拍打它。即使它没有/也不会打扰编译器，您的主要受众是其他人阅读代码。至少IMO，您应该使用constexpr向他们传达一个相当具体的含义，并将其打到其他表达式上，因为您可能会产生误导。我认为读者想知道一个标记为constexpr的函数发生了什么，但仅用作正常的运行时函数，这是公平的。

同时，如果你有一个老实说期望在编译时使用的功能，而你还没有那样用 ，那么标记因为constexpr可能会更有意义。

Answer 2

为什么我懒得尝试将constexpr放在列表表格中的每个机会，并且没有特别的顺序：

• 我不会编写经常
的单行函数
• 当我写一个单行时，它通常委托给一个非constexpr函数（例如std::get最近出现了几次）
• 他们操作的类型并不总是文字类型;是的，引用是文字类型，但如果引用的类型本身不是文字，我无论如何都无法在编译时拥有任何实例
• 他们返回的类型并不总是字面意思
• 就语义而言，它们在编译时并不是全部有用甚至是有意义的
• 我喜欢将实现与声明分开

Constexpr功能有很多限制，它们只是特殊用途的利基。通常不是优化或理想的超级功能集。当我做写一个时，通常是因为单独的元函数或常规函数不会削减它，我对它有一种特殊的心态。 Constexpr函数不像其他函数那样品味。

我对constexpr构造函数没有特别的意见或建议，因为我不确定我是否可以完全理解它们并且用户定义的文字尚不可用。

Answer 3

是即可。我相信无论你能做什么，把const这样做都是一种很好的做法。例如，在您的class中，如果给定的方法没有修改任何成员，那么您总是倾向于在最后添加const关键字。

除了语言方面，提及const ness也是未来程序员/审稿人表达该区域内持久性的一个很好的指示。它涉及良好的编码实践并且还增加了可读性。例如（来自@Luc）

constexpr int& f(int& i) { return get(i); }

现在提出constexpr表明get()也必须是constexpr。

我认为constexpr没有任何问题或含义。

修改：constexpr的一个额外优势是，在某些情况下，您可以将它们用作template参数。

Answer 4

在以下方面（就大多数事情而言），我倾向于与Scott Meyers达成共识：“尽可能使用{'Breakfast': [('Coffee', 2), ('Eggs', 3)], 'Dinner': [('Shrimp', 10), ('Fish&Chips', 7)], 'Lunch': [('Burger', 5), ('Fries', 6), ('Salad', 9), ('Steak', 9)]} ”（来自 Effective Modern C ++ 的第15条），特别是如果您是提供供他人使用的API。当您希望使用函数执行编译时初始化时，可能确实令人失望，但不能这样做，因为库没有声明它constexpr。此外，所有类和函数都是API的一部分，无论是世界使用的还是团队使用的。因此，请尽可能使用它，以扩大其使用范围。

constexpr

也就是说，// Free cup of coffee to the API author, for using constexpr // on Rect3 ctor, Point3 ctor, and Point3::operator* constexpr Rect3 IdealSensorBounds = Rect3(Point3::Zero, MaxSensorRange * 0.8); 是接口的一部分，因此，如果该接口自然不适合constexpr的内容，请不要使用它，以免您稍后不得不破坏API 。也就是说，不要仅仅因为当前唯一的实现就可以将constexpr提交给接口。