我需要静态转换我的数字模板值吗？

Question

我目前正在编写一个模板化的 c++ 物理库。在我的函数中，我经常需要明确比较或设置某些数值。我的目标是编写尽可能通用的库，因此我希望尽可能支持浮点和整数类型。

为了获得正确的类型，我经常在我的代码中使用对T 的显式强制转换。在我的所有情况下，这当然被解释为static_cast。因此，我的问题是：我真的需要static_cast 这些值吗？或者我是否可以通过做/不做来获得运行时开销？

一个例子：

我目前有这样的功能：

template <class T> auto is_elliptic(T eccentricity, T semi_major_axes = T(1)) {
   return T(0) <= eccentricity < T(1) && T(0) < semi_major_axes;
}

不过，我也可以这样写：

template <class T> auto is_elliptic(T eccentricity, T semi_major_axes = T(1.0)) {
   return T(0.0) <= eccentricity < T(1.0) && T(0.0) < semi_major_axes;
}

像这样：

template <class T> auto is_elliptic(T eccentricity, T semi_major_axes = 1) {
   return 0 <= eccentricity < 1 && 0 < semi_major_axes;
}

或者像这样：

template <class T> auto is_elliptic(T eccentricity, T semi_major_axes = 1.0) {
   return 0.0 <= eccentricity < 1.0 && 0.0 < semi_major_axes;
}

我不太关心这两个版本的可读性。我也不关心这样一个事实，在这里使用整数类型可能是没用的。我只想知道：

• 这些实现之间有区别吗？
• 如果是，是什么？
• 另外，此代码编译器上可能的优化是否取决于？

编辑：

• 如果我想支持自定义数字类型，是否会进行任何更改？

编辑：

正如 cmets 中所指出的，上面使用的链式比较实际上是错误的。代码应该是这样的：

return T(0) <= eccentricity && eccentricity < T(1) && T(0) < semi_major_axes;

此外，可以使用constexpr 版本对代码进行运行时优化：

template <class T> constexpr auto is_elliptic(T eccentricity) {
    return T(0) <= eccentricity && eccentricity < T(1);
}
template <class T> constexpr auto is_elliptic(T eccentricity, T semi_major_axes) {
    return T(0) <= eccentricity && eccentricity < T(1) && T(0) < semi_major_axes;
}

Answer 1

取决于你想要什么。

---

此答案假定T 是int 或float（尽管它适用于double、long 或具有类似行为的自定义类型），并且x 的类型为T .

• 如果使用演员表：

这很容易理解。但是，请注意常量在T 类型中不可表示的情况。 0.5>x 与 (int)0.5>x 不同。

• 如果不使用演员表：

[I]如果提升的操作数具有不同的类型，则应用额外的一组隐式转换，称为通常的算术转换，目标是生成通用类型 [...]。

（来自https://en.cppreference.com/w/cpp/language/operator_arithmetic）

| T     | Comparison | Equivalent to |
+-------+------------+---------------+
| int   | 0<x        | 0<x           |
| int   | 0.f<x      | 0.f<(float)x  |        (*)
| float | 0<x        | (float)0<x    |
| float | 0.f<x      | 0.f<x         |

对于(*)，比较在float 上完成，而转换常量 (int(0.f<x)) 将在整数上进行比较。其他情况也一样。

关于编译器开销：编译可能会稍微慢一点，但考虑到编译标准库头文件的速度有多慢，应该没什么关系。