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

Question

我们显然无法做到一切constexpr.如果我们什么都不做constexpr,那就不会有任何大问题.到目前为止,很多代码都没有编写.

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

Answer 1

它不会打扰编译器.如果您在不符合要求的代码上使用它,编译器将(或者应该)给出诊断constexpr.

与此同时,我有点犹豫,因为你可以在那里拍打它.尽管它不会/不会打扰编译器,但您的主要受众是其他人阅读代码.至少IMO,你应该用它constexpr来传达一个相当具体的含义,然后把它放在其他表达式上,因为你可能会产生误导.我认为读者想知道一个被标记为a constexpr但仅用作正常运行时函数的函数会发生什么事情是公平的.

同时,如果您有诚实的功能预计在编译时使用,而你只是还没有使用它的方式却,将其标记为constexpr可能使相当多的感觉.

Answer 2

为什么我懒得尝试constexpr以列表形式抓住每个机会,并且没有特别的顺序:

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

Constexpr功能有很多限制,它们只是特殊用途的利基.通常不是优化或理想的超级功能集.当我不写一个,它往往是因为元函数或单独常规功能不会削减它,我有这方面的特殊心态.Constexpr功能不味道像其他功能.

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

Answer 3

我倾向于同意 Scott Meyers 的观​​点（对于大多数事情）：“constexpr尽可能使用”（来自《Effective Modern C++ 》第 15 条），特别是当您提供 API 供其他人使用时。当您希望使用函数执行编译时初始化，但由于库没有声明它而无法执行时，这可能会非常令人失望constexpr。此外，所有类和函数都是 API 的一部分，无论是由全世界使用还是仅由您的团队使用。因此，尽可能使用它，以扩大其使用范围。

// 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是接口的一部分，因此，如果接口不自然地适合某些可以的东西constexpr，请不要承诺它，以免以后不得不破坏 API。也就是说，不要constexpr仅仅因为当前唯一的实现可以处理它而承诺该接口。