c++ - 三元运算符的第二个或第三个参数为空白或什么都不做

Question

三元运算符是否可以有一个空白的第二个或第三个参数，或者有一个非上下文特定的并且意味着“什么都不做”的参数？在下面的例子中，我想要一个三元运算符将一个整数变量乘以二，如果它是偶数，否则什么也不做。对于第三个参数，除了自赋值、加或减零、乘以或除以 1 之外，我想不出任何其他东西。无论如何，它们都是特定于上下文的。我想要一些对所有三元运算符都意味着“什么都不做”的东西。我尝试将参数留空，但无法编译。

#include <iostream>

int main()
{
    int x = 5;
    (x % 2 == 0) ? x *= 2 : x = x; // or x += 0, x -= 0, x *= 1, or x /= 1
    std::cout << x << std::endl;
    return 0;
}

有没有不涉及重述已经存在的变量、函数或对象的解决方案？例如，考虑两个函数 foo 和 goo，其中 foo 返回一个 bool。假设由于某些原因(例如后续调用的状态更改)无法再次调用这两个函数。

int main()
{
    ( foo() ) ? goo() : ; // won't compile
    return 0;
}

Answer 1

如果你打算使用三元运算符，你可能想要分配它的结果:

x = (x % 2 == 0) ? 2 * x : x;

就个人而言，我认为我只需要使用一点点数学:

x <<= ((x & 1) ^ 1);

x&1 给出 x 的最低有效位，如果 x 为奇数则为 1，如果为偶数则为 0。 ^ 1 部分翻转该位，因此如果 x 是偶数，它给出 1，如果 x 是奇数，它给出 0。然后我们将 x 左移那么多位。移动 0 位显然会使 x 保持不变。左移一位将 x 乘以 2。

至于为什么后者会(或至少可能)更可取，这主要归结为一个问题，即您是否真的关心这种情况下的性能。如果您处在性能无关紧要的情况下，那么 if ((x%2)==0) x *= 2; 可能是您的最佳选择。

我至少猜到这个问题的至少部分原因是对效率的关注。如果是这样，纯数学方法可能是更好的选择。例如，让我们考虑一下 VC++ 为两者生成的代码:

; mathematical version:
mov eax, DWORD PTR _x$[esp-4]
mov ecx, eax
not ecx
and ecx, 1
shl eax, cl

[注意:对于此源代码，g++ 生成几乎相同的目标代码]。

忽略从内存加载 x 的(可能的)时间，这应该在任何 Intel 处理器上执行不超过 4 个时钟周期，回到 386 左右。更好的是，我d 期望任何处理器的任何编译器都能产生非常相似的结果——对于几乎任何合理的处理器来说，从源代码到汇编语言的直接、直白的翻译将在四个指令中完成实际的数学运算，每条指令大约是尽可能简单和快速。

使用if语句的版本是这样的:

; Line 2
    mov ecx, DWORD PTR _x$[esp-4]
    mov eax, ecx
    and eax, -2147483647            ; 80000001H
    jns SHORT $LN5@f
    dec eax
    or  eax, -2                 ; fffffffeH
    inc eax
$LN5@f:
    lea eax, DWORD PTR [ecx+ecx]
    je  SHORT $LN1@f
; Line 3
    mov eax, ecx
$LN1@f:

随着编译的进行，这还算不错。它至少避免了 div，这将是实现 %2 的明显方式。不幸的是，它仍然不够聪明以具有竞争力——它仍然有几个分支，其中一个可能不是很容易预测，所以大约一半的时间我们会为预测错误的分支付出代价。

根据编译器的不同，您可以(并且将会)看到比这更好的结果。例如，改用 g++，我得到这个:

    mov eax, DWORD PTR [ebp+8]
    and eax, 1
    test    eax, eax
    jne L2
    sal DWORD PTR [ebp+8]
L2:
    mov eax, DWORD PTR [ebp+8]

虽然这段代码肯定比 VC++ 做得更好，但它仍然远不及数学版本那么好。特别是，除非最低有效位是相当可预测的偶数或奇数，否则该分支可能有大约一半的时间被误预测。

底线:在最好的情况下，这可能接近匹配数学版本——但这将取决于编译器和输入数据的配合。除了编译器和输入数据的最偶然组合之外，它几乎肯定会慢至少 2 倍，而 10 倍甚至不会让人感到意外。

当然，根据我使用的标志、编译器版本等，我可能能够从任一编译器中获得比实际更好的结果。如果坚持不懈，我可能甚至会得到与代码的数学版本相同的结果。除非我非常了解目标编译器和 CPU，否则我什至不确定能否获得同样好的结果——而且我认为它们变得更好的可能性充其量是极其渺茫的。