Каков будет результат действия a++-++a?

07.08.2013, 17:16. **Показов** 12126. **Ответов** 54

Студворк — интернет-сервис помощи студентам

Подскажите, пожалуйста, каков результат действия a++-++a? 0?
Изначально a = 0

@castaway · 14.08.2013, 23:21

Сообщение от Lokomoss

да,как уже кто-то писал gcc под виндой выдает -1

У меня выдает 0.

Сообщение от Lokomoss

но с точки зрения операций логично выдавать 2

Если не брать в расчет точку следования, то логично, что ожидаемый результат будет 0 (приоритеты операций).

Сообщение от Lokomoss

а++-++а эквивалентно= ((а+1)-а)+1=2

Далеко не эквивалентно.

@Lokomoss · 15.08.2013, 10:29

во-первых,не знаю,почему у вас выдает 0,возможно все-таки не windows стоит или среда чуть другая
приоритет операций,согласна.и я его верно описала. можно почитать любую литературу и убедиться в этом
оно эквивалентно.
я не спорила бы,если бы на практике это сама не проверила. взять и принтовать экран не сложно и вставить сюда.

@lowercase · 15.08.2013, 10:34

а получится, как я и передпологал, холивар.
зы.

@Nameless One · 15.08.2013, 10:40

Сообщение от castaway

Если не брать в расчет точку следования, то логично, что ожидаемый результат будет 0 (приоритеты операций).

Что логично и при чем здесь приоритеты операций? Вопрос на засыпку: в выражении a++ - ++a какой операнд будет вычислен первым? Первый (a++) или второй (++a)?

Точки следования ограничивают порядок вычислений. В C/C++ же порядок вычисления операций (за некоторыми исключениями: логические операторы, тернарный оператор, оператор запятой) не определён.

@Lokomoss · 15.08.2013, 10:46

по-моему,все согласятся,что первый а++, вот потом да...тут как уже понимается все зависит от среды. потому что ,так как я сжу по тому,то выдает мне мой запуск программы,то там никакой логики нет ибо ответ -1,
если же вспоминать всякие хитрости ,в плане,все-таки приоритет , то по логике должен выполниться вторым ++а-а,а потом увеличение только на 1. Так все-таки снова вспоминая разницу между ++а и а++,надо помнить,что один сразу увеличивает,а потом все выполняет,а другой наоборот.

@castaway · 15.08.2013, 10:59

1. a++ (постфиксный инкремент - приоритет 2)
2. ++a (префиксный инкремент - приоритет 3)
3. cout << a - a; (бинарный минус - приоритет 6)
Что не понятно?

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
#include <iostream>
 
using namespace std;
 
int main()
{
    int a = 0;
    std::cout << "a = 0, a++ - ++a = " << a++ - ++a << std::endl;
    return 0;
}

@Nameless One · 15.08.2013, 11:24

Сообщение от castaway

Что не понятно?

Не знаю, на что ты отвечал, но точно не на мой вопрос.

У обоих инкрементов приоритет выше, чем у бинарного минуса, поэтому всё выражение парсится так: (a++) - (++a). Вот здесь роль приоритета заканчивается.

Далее для того, чтобы вычислить значение выражения (а именно, найти значение разности), необходимо предварительно вычислить оба аргумента бинарного минуса. В зависимости от того, в каком порядке вычисляются эти аргументы, мы получим разные значения. А соль в том, что порядок вычисления операторов в C/C++ не определён (исключения в моём предыдущем сообщении), поэтому это полностью и целиком зависит от того, какой компилятор используется (и какая у него версия). Именно поэтому у тебя и у Lokomoss получились разные результаты.

К слову, у меня при компиляции clang'ом выдаётся -2, и тут совершенно нечему удивляться:

@castaway · 15.08.2013, 11:26

Сообщение от Nameless One

(a++) - (++a). Вот здесь роль приоритета заканчивается.

Собственно, я это и имел в виду.

Evg · 15.08.2013, 11:45

Сообщение от Lokomoss

но с точки зрения операций логично выдавать 2. а++-++а эквивалентно= ((а+1)-а)+1=2. если же выполнять наоброт:
++a-a++,то результат всегда будет ноль,и это понятно : потому что это эквивалентно такому
1+(а-(а+1))

Когда люди пишут программы, то единственный документ, на основании которого строятся ожидания результата выполнения программы - это стандарт языка. Все прочие высосанные из пальца доводы и размышления о логичности или нелогичности, а так же мнения авторов сомнительных книг, признанных и непризнанных классиков, гениев и пр. никому не интересны и идут лесом

Добавлено через 5 минут
Вариант типа "++a + a++" - слишком симметричный, а в эмпирически решаемых вопросах никогда не надо рассматривать симметричных случаев. Надо взять более кособокий пример:

C
1
2
3
4
5
6
7
8
9
#include <stdio.h>
 
int main (void)
{
  int arr[2] = { 10, 100 };
  int *p = arr;
  printf ("%d\n", *++p + *p++);
  return 0;
}

как только берём такой пример, то сразу становится ясно, что все "логичные" доводы о том, в каком порядке должны выполняться операции, сразу же теряют свою логику после того, как мы убеждаемся, что при любом зафиксированном порядке вычислений мы наблюдём один и тот же эффект: от перестановки слагаемых поменялась сумма.

@Nameless One · 15.08.2013, 11:52

Сообщение от Evg

что при любом зафиксированном порядке вычислений мы наблюдём один и тот же эффект: от перестановки слагаемых поменялась сумма.

Разве это не аргумент в пользу того, что порядок вычисления имеет значение?

Evg · 15.08.2013, 12:06

Сообщение от Nameless One

Разве это не аргумент в пользу того, что порядок вычисления имеет значение?

Это объяснение того, почему такие коды является undefined и того, что тут нельзя придумать какое-либо определённое поведение (и именно поэтому оно undefined).

И именно по таким причинам в языках типа C есть понятие undefined behavior, связанное с порядком вычисления операндов. Всякие неопределённые поведения в случае НЕинициализированных переменных, обращений по кривым указателям и т.п. - с этим обычно вопросов не возникает. Вопросы возникают с неопределённым поведением в арифметических операциях и т.п.

Добавлено через 1 минуту

Сообщение от Nameless One

порядок вычисления имеет значение

Имеет значение то, в каком порядке вычислит аргументы компилятор, а не то, в каком порядке они записаны. При этом порядок вычислений НЕ определён стандартом языка (т.е. компилятор вправе сам решать, в каком порядке он вычислит аргументы). И не может быть определён, оставаясь при этом логичным

@voral · 15.08.2013, 12:42

Сообщение от Evg

И не может быть определён, оставаясь при этом логичным

А почему? Разве, если отказаться от оптимизации, нельзя установить логику чтения слева на право? Она вроде применяется, например в тех же условных операторах при склеивании условий через или. Или я не прав?

Evg · 15.08.2013, 12:49

Сообщение от voral

Разве, если отказаться от оптимизации, нельзя установить логику чтения слева на право? Она вроде применяется, например в тех же условных операторах при склеивании условий через или

Приведи мне любую логику, при которой значения выражений

C
*p++ + *++p

и

C
*++p + *p++

будут равны (ведь с 1-го класса мы знаем, что от перестановки слагаемых сумма не меняется)

Добавлено через 1 минуту

Сообщение от voral

Она вроде применяется, например в тех же условных операторах при склеивании условий через или

Там другая логика. Основанная на том, что для && и || если левого аргумента достаточно для вычисления всего выражения, то правый аргумент не вычисляется. Не помню, как это по научному называется. Например, "false && expr" всегда равно "false", а потому "expr" не вычисляется

@voral · 15.08.2013, 12:51

Согласен. А если ограничиться операциями где перестановка меняет результат?

Evg · 15.08.2013, 12:52

Про логические операции && и || это ты верно заметил. Их текущее поведение точно так же "нелогично", поскольку мы знаем, что в математике от перестановки аргументов логических "и" и "или" результат не меняется, а в программировании, получается, результат может быть и разным. Но в случае логических операций, судя по всему, было проще пожертвовать математической логикой и зафиксировать порядок вычислений.

Добавлено через 46 секунд

Сообщение от voral

Согласен. А если ограничиться операциями где перестановка меняет результат?

Тогда получится, что для операции сложения у нас действуют одни правила, для операции вычитания - другие. Если я правильно твой вопрос понял

@Nameless One · 15.08.2013, 12:53

Сообщение от voral

Она вроде применяется, например в тех же условных операторах при склеивании условий через или

Да, потому, что логические операторы — это т.н. short-circuit операторы, которые вычисляют свои правые операнды только в случае необходимости. А это без строгого порядка вычислений слева-направо было бы невозможно реализовать.

Сообщение от voral

Разве, если отказаться от оптимизации, нельзя установить логику чтения слева на право?

Порядок вычисления можно было бы явно установить (как это сделано в некоторых языках), но, насколько я знаю, изменение порядка вычисления позволяет производить некоторые оптимизации, чем и пользуются разработчики компиляторов, поэтому такое поведение и прописано в стандарте.

@voral · 15.08.2013, 12:53

Сообщение от Evg

Там другая логика. Основанная на том, что для && и || если левого аргумента достаточно для вычисления всего выражения, то правый аргумент не вычисляется. Не помню, как это по научному называется. Например, "false && expr" всегда равно "false", а потому "expr" не вычисляется

Да. Но ведь этим можно пользоваться, например в парвом выражении проверяя существование объекта, а в левом один из его параметров. Если бы вычислялись оба то была бы вероятность падения проги.....

@Nameless One · 15.08.2013, 12:54

Сообщение от Evg

Если я правильно твой вопрос понял

Я вообще его так понял: «почему для C не определён порядок вычисления операций (и аргументов при вызове функций)?»

@voral · 15.08.2013, 12:56

Сообщение от Evg

Тогда получится, что для операции сложения у нас действуют одни правила, для операции вычитания - другие. Если я правильно твой вопрос понял

Сообщение от Nameless One

которые вычисляют свои правые операнды только в случае необходимости

Согласен.

@Nameless One · 15.08.2013, 13:01

Сообщение от Evg

поскольку мы знаем, что в математике от перестановки аргументов логических "и" и "или" результат не меняется, а в программировании, получается, результат может быть и разным.

Это делается скорее не потому, что результат выражения A && B при перестановке операндов может измениться, а в целях оптимизации, т.к. в определённых случаях вычисление левого операнда задаёт значение всего выражения независимо от того, какое значение у правого операнда. А так как вычисление правого операнда может быть потенциально затратным, то и пришли к выводу, что в таких случаях лучше их не вычислять.

А порядок вычисления выражений (не только логических) в математике, кстати, тоже не определён, т.к. он там ни на что не влияет, побочных эффектов-то нету.

Новые блоги и статьи Все статьи Все блоги /
Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .	Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .
Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .	мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))

kimi07

	Каков будет результат действия a++-++a? 07.08.2013, 17:16. Показов 12126. Ответов 54 Метки нет (Все метки) Подскажите, пожалуйста, каков результат действия a++-++a? 0? Изначально a = 0

@Lokomoss 13 / 2 / 2 Регистрация: 17.10.2012 Сообщений: 57
	15.08.2013, 10:29
	во-первых,не знаю,почему у вас выдает 0,возможно все-таки не windows стоит или среда чуть другая приоритет операций,согласна.и я его верно описала. можно почитать любую литературу и убедиться в этом оно эквивалентно. я не спорила бы,если бы на практике это сама не проверила. взять и принтовать экран не сложно и вставить сюда. 0

@lowercase 213 / 202 / 85 Регистрация: 09.05.2012 Сообщений: 494
	15.08.2013, 10:34
	а получится, как я и передпологал, холивар. зы. 0

@Lokomoss 13 / 2 / 2 Регистрация: 17.10.2012 Сообщений: 57
	15.08.2013, 10:46
	по-моему,все согласятся,что первый а++, вот потом да...тут как уже понимается все зависит от среды. потому что ,так как я сжу по тому,то выдает мне мой запуск программы,то там никакой логики нет ибо ответ -1, если же вспоминать всякие хитрости ,в плане,все-таки приоритет , то по логике должен выполниться вторым ++а-а,а потом увеличение только на 1. Так все-таки снова вспоминая разницу между ++а и а++,надо помнить,что один сразу увеличивает,а потом все выполняет,а другой наоборот. 0

@voral 3061 / 1465 / 265 Регистрация: 16.03.2008 Сообщений: 6,512 Записей в блоге: 2
	15.08.2013, 12:51
	Согласен. А если ограничиться операциями где перестановка меняет результат? 0

Каков будет результат действия a++-++a?

Решение