在 C++ 中,在某些上下文中,圆括号可能会改变封闭表达式的含义(对于给定的上下文)。例如,decltype(expr) 和 decltype((expr)) 通常会产生不同的类型:
int x;
decltype(x) a=x; // type int; a initialized with a copy of x
decltype((x)) b=x;//type int&; b is a reference to x; extra parentheses matter!
但是 C 呢?
将宏参数括在括号中是 C 中的常见做法,这会产生一些意想不到的副作用吗?
[编辑]更准确地说,如果括号对于分组来说是多余的,它们可能会改变程序的含义吗?
我只考虑表达式(不考虑其他语法元素,例如类型、函数参数列表等)。
最佳答案
我认为答案是否定的。
我不知道在任何情况下添加一对额外的不必要的括号,如在 ((blah))
中,会改变含义。正如您所说,这对大多数宏定义至关重要。
但是,在很多情况下,显式分组会导致与数学规则无关的变化。我指的不是 (1+2)*3
;那只是数学。我的意思是编译器最终会生成一个不同但等效的代码序列,该代码序列的效率更高,也可能更低。
例如,考虑这个功能;
float fourth_power (float n) {
return n*n*n*n;
}
它可以对这个函数执行不同的操作:
float fourth_power (float n) {
return (n*n)*(n*n);
}
在纯数学中,结果应该是相同的,但实际上对于有限大小的浮点值,您可以获得不同的数字答案,但这不是我在这里谈论的内容。
我所说的变化是第二种形式运行得更快。如果您知道自己只使用较小的数字(其中 float 的限制不是问题),那么您可能希望以第二种方式对其进行编码以提高速度。
事实上,如果您使用 -ffast-math
,我认为 GCC 会进行这种转换,但通常情况下编译器会安全运行。
这是一个可能适用于所有编译器的示例(因为它与数值准确性有关),但是有许多示例明显任意分组决策可以使特定编译器沿着不同的内部决策路径,并且可以有有趣的,以及性能、代码大小等方面的可衡量差异。
关于c - C 中的额外括号,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19680953/