为什么后缀操作符++的优先级高于前缀操作符++？ [英] Why does postfix operator++ have higher precedence than prefix operator++?
问题描述
定义这种方式，我们既不能做 ++ x ++ 也不能 ++ x - 。但另一方面，（++ x）++ 和（++ x） - 表达式：（++ x）++ 增量 x 乘以2并返回值 （++ x） - 本质上等同于 x + 1 ，但完全避免了必须调用<$ c $
因此，为什么优先级没有定义为 ++ x ++ 自动展开为（++ x）++ ，而不是 ++（x ++）？对于后者有一些隐藏的意义我不明白，还是只是为了保持优先级一个简单的列表与所有前缀运算符组成一个单一的级别？
EDIT 确定，我没有明确说明，但是：当然我的意思是 x 是用户定义的类型。对于内置类型，（x + = 2）-1 当然优于（++ x）++ ， x + 1 是很多比（++ x） - 。我想到的情况是迭代到一个相当复杂类型的半关联容器，其中运算符 + = 和 + （被设计用于随机存取）必须重建高速缓存以便对一般请求有效地工作，并且因此比 ++ 慢一个数量级。但是，当然我可以修改它们，如果参数是一个非常小的整数，总是先检查，在这种情况下，只是调用 operator ++ ，而不是随机访问过程。这应该工作很好在这里，虽然我可以想象我可能在某一点有一个情况，我想要 operator + = 总是去随机访问的方式，无论多么小
对我来说，我的结论是：
具有一个简单易记的优先顺序列表的优点，其中所有后缀操作符都在任何前缀运算符足以容忍总是必须使用括号来组成前缀和后缀运算符的小缺点
++/-，因为这个组合很少使用。
更简单的C这样做，而似乎很可能是真实的原因，对我来说是不太令人满意，因为 ++ x ++ 根本不允许 在C中，我们可以重新定义这个组合而不损害任何现有的代码。
无论如何，我将继续使用 ） - ，因为圆括号确实不会伤害这么多。
C规则，并且显然这些不是固定的，考虑到操作符重载和习惯用尚未被发明的语言发明。
查看 DM Ritchie主页，看到这个优先级已经存在于B中（一元运算符被右边绑定。因此 - ！x ++ code> - （！（x ++）） ），我在BCPL中没有看到增量运算符。 p>
Defined this way, we can do neither ++x++ nor ++x--. But on the other hand, both (++x)++ and (++x)-- are useful expressions: (++x)++ increments x by two and returns the value "in the middle", while (++x)-- is essentially equivalent to x+1 but completely avoids having to call operator+, which can be quite useful sometimes.
So why is the precedence not defined to have ++x++ automatically expand to (++x)++ rather than ++(x++)? Is there some hidden meaning to the latter which I don't understand, or is it just to keep the precedence a simple list with all prefix operators making up one single level?
EDIT Ok, I didn't explicitly say it, but: of course I meant x to be user-defined type. For built-in types, (x+=2)-1 is of course better than (++x)++, and x+1 is a lot better than (++x)--. The situation that I have in mind is an iterator to a rather complicated type of semi-associative container, where operators += and + (being designed for random access) have to rebuild a cache in order to work efficiently for general requests, and are therefore an order of magnitude slower than ++. But of course I can modify them to always check first if the argument is a very small integer, and in that case just call operator++ repeatedly instead of doing the random-access procedure. That should work fine here, though I could imagine I might at some point have a situation in which I want operator+= to always go the random-access way, regardless of how small numbers I present it.
So... for me, I would conclude the answer to be:
the advantage of having a simple and well-memorizeable precedence list in which all postfix operators come before any of the prefix operators is sufficient to tolerate the minor drawback of always having to use parentheses to compose pre- and postfix operators
++/--, as this composition is used very seldom.
The simpler "C does it this way", while it seems likely to be the real reason, is far less satisfying in to me, because since ++x++ was not allowed at all in C it would have been possible to redefine this very composition without damaging any existing code.
Anyway, I will go on using (++x)--, as the parentheses really do not hurt so much.
C++ standard just kept the C rules and obviously those weren't fixed considering operator overloading and idioms yet be invented in a yet to be invented language.
Looking at what is available in D.M. Ritchie Home Page, on see that this precedence is already present in B (Unary operators are bound right to left. Thus -!x++ is bound -(!(x++)) in Users' Reference to B) and I didn't see increment operators in BCPL.
这篇关于为什么后缀操作符++的优先级高于前缀操作符++？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
