Определенный таким образом, мы не можем сделать ни ++x++, ни ++x--. Но с другой стороны, как (++x)++, так и (++x)-- являются полезными выражениями: (++x)++ увеличивает x на два и возвращает значение "в середине", а (++x)-- по существу эквивалентно x+1, но полностью избегает необходимости называть operator+, что иногда может быть весьма полезным.
Итак, почему приоритет не определен, чтобы ++x++ автоматически расширялся до (++x)++, а не ++(x++)? Есть ли какой-то скрытый смысл для последнего, который я не понимаю, или просто сохранить приоритет простым списком со всеми операторами префикса, составляющими один уровень?
EDIT Хорошо, я не сказал этого явно, но: конечно, я имел в виду x для пользовательского типа. Для встроенных типов (x+=2)-1, конечно, лучше, чем (++x)++, а x+1 намного лучше, чем (++x)--. Ситуация, которую я имею в виду, является итератором для довольно сложного типа полуассоциативного контейнера, где операторы += и + (предназначенные для произвольного доступа) должны перестраивать кеш, чтобы эффективно работать для общих запросов, и, следовательно, на порядок медленнее, чем ++. Но, конечно, я могу изменить их, чтобы всегда проверять, если аргумент является очень маленьким целым числом, и в этом случае просто вызывать operator++ несколько раз, а не выполнять процедуру произвольного доступа. Это должно сработать хорошо, хотя я мог представить, что в какой-то момент я мог бы иметь ситуацию, в которой я хочу, чтобы operator+= всегда проходил случайный доступ, независимо от того, как небольшие числа я представляю его.
Итак... для меня, я бы пришел к заключению:
преимущество наличия простого и хорошо запоминаемого списка приоритетов, в котором все операторы постфикса доходят до того, как какой-либо из префиксных операторов достаточно, чтобы терпеть незначительный недостаток, когда всегда приходится использовать круглые скобки для составления пред- и постфиксных операторов
++/--, так как эта композиция используется очень редко.
Более простой "C делает это таким образом", хотя он, вероятно, является реальной причиной, гораздо менее удовлетворяет мне, потому что, поскольку ++x++ вообще не разрешалось в C, было бы возможно переопределить этот самый состав, не повреждая какой-либо существующий код.
В любом случае, я продолжу использовать (++x)--, так как скобки действительно не так больно.