Постфиксные инкремент и декремент

Операции «++» и «--» широко используются в языках с С-подобным синтаксисом. Перед обсуждением этих операций необходимо сразу же сделать оговорку. Здесь анализируется не принцип записи обозначения операции после операнда, а свойство таких операций выполнять действие над операндом по окончании всех остальных операций.

         В чём аномальность этих операций? В справочных руководствах по С/С++ унарные операции «++» и «--» как в префиксном, так и в постфиксном варианте имеют приоритет, равный 1 (всего приоритетов 16, от 0 до 15; 0 — наивысший приоритет). Для префиксных операций это справедливо безо всяких замечаний.

         Постфиксные «++» и «--» же при синтаксическом анализе так же имеют приоритет, равный 1. А при выполнении появляется «фокус»: они выполняются в последнюю очередь, после выполнения всего выражения. Получается, что эти операции помимо обычного существования имеют «параллельную реальность». В алголоподобных языках операции и функции могут иметь операнды в количестве от нуля и более. Но один операнд может принадлежать только одной операции или функции. Но в С/С++ это не так. «Отклонением от нормы» как раз являются «++» и «--». Возьмём пример:

	f(a++);

	f(++a);

   a = (b++);

do { *dst++ = *src++;} while (*src);

do { *dst = * src; ++dst; ++src;) while (*src);

BigInt& operator++(BigInt& op1, BigInt op2) { ... }; // Это постфиксный инкремент
BigInt& operator++(BigInt& op1)             { ... }; // А это префиксный инкремент

Опубликовано: 2012.09.25, последняя правка: 2014.12.23    13:37

✅  2014/04/26 11:45, Utkin          #0 

✅  2014/05/01 15:05, Автор сайта          #1 

✅  2014/06/17 04:44, 87.241.204.6          #2 

Это краткая и удобная запись, позволяющая записывать имя объекта только единожды

✅  2014/06/17 16:16, Автор сайта          #3 

✅  2014/06/19 10:02, utkin          #4 

✅  2014/06/19 17:47, Автор сайта          #5 

В = А + 1

✅  2014/06/23 09:25, utkin          #6 

✅  2014/06/23 13:48, Автор сайта          #7 

✅  2014/06/30 12:23, utkin          #8 

Это личные предпочтения всех, кто программирует на Си-подобных языках: C, C++, C#, Objective C, D, Java, Cyclone и т.д.

✅  2014/06/30 17:28, Автор сайта          #9 

int  array[10];
int* ptr = array;
++ ptr;
*ptr = 99;      // array[1] теперь равен 99
ptr = ptr + 1; // это по-паскалевски!
*ptr = 98;    // array[2] теперь равен 98

✅  2015/02/11 17:19, Автор комментария          #10 

✅  2015/02/11 20:40, Автор сайта          #11 

✅  2015/09/03 14:49, Александр          #12 

✅  2016/04/29 04:29, Олег          #13 

Сам факт существования Паскаля и его использование для написания вполне рабочих программ говорит о том, что данные операции не обязательны вообще. Можно рассматривать как частный случай синтаксического сахара.

✅  2016/04/29 11:30, Автор сайта          #14 

✅  2016/05/05 14:18, utkin          #15 

Ты серьезно?! Сам факт СУЩЕСТВОВАНИЯ Паскаля?! Что-то Вас занесло, уважаемый ))

✅  2016/05/05 14:19, utkin          #16 

А ещё сам факт существования Brainfuck говорит о том, что в языке программирования можно обойтись без букв.

✅  2016/05/05 14:36, Автор сайта          #17 

✅  2016/08/06 00:11, Александр          #18 

void f(int& val){/* */};

do { *dst = * src; ++dst; ++src;) while (*src);

✅  2016/08/23 03:59, xDDGx          #19 

do { *dst++ = *src++;} while (*src);

✅  2016/10/31 08:43, rst256          #20 

Теперь понимаю, что делают «&» и «++». Они по своей сложности не очень отличаются.

void iseq(int a, int b){ assert(a==b); }
void ismt(int a, int b){ assert(a+1==b); }

int main(int argc, char **argv){

{ int j=100, *jp; jp=&j; iseq(j++, j); assert(j==101); } //100, 100
{ int j=100, *jp; iseq(j++, j); jp=&j; assert(j==101); } //100, 100
{ int j=100, *jp; iseq(j++, j); assert(&j && j==101); } //100, 100
{ int j=100, *jp; ismt(j++, j); assert(j==101); } //100, 100

{ int j=100, *jp; jp=&j; printf("\n%d, %d\n", j++, j); assert(j==101); } //100, 100
{ int j=100, *jp; printf("%d, %d\n", j++, j); jp=&j; assert(j==101); } //100, 100
{ int j=100, *jp; printf("%d, %d\n", j++, j); assert(&j && j==101); } //100, 100
{ int j=100; printf("%d, %d\n", j++, j); assert(j==101); } //100, 101

{ int j=100, *jp; jp=&j; printf("\n%d, %d\n", ++j, j); assert(j==101); } //101, 100
{ int j=100, *jp; printf("%d, %d\n", ++j, j); jp=&j; assert(j==101); } //101, 100
{ int j=100; printf("%d, %d\n", ++j, j); assert(j==101); } //101, 101
	 
return 0;
}

✅  2017/08/03 12:30, Алексей          #21 

Аргумент «а» сначала является операндом функции «f()», а затем , после её выполнения, операнд «а» является операндом операции «++».

Аргумент «а» копируется в операнд функции «f()», затем, до выполнения тела функции, над «а» производится «++», и затем выполняется тело функции «f()» с исходным операндом.

f(a++, a++);

✅  2022/04/29 15:34, stein47          #22 

a++;

++b;

✅  2022/04/29 15:47, Gudleifr          #23 

Но чревато "фокусами" и ошибками

✅  2022/04/29 16:18, Автор сайта          #24 

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

можно оставить только постфиксную запись, но смысл приравнять к префиксной. Правда, это уже разрыв "сишного наследия".

✅  2024/03/27 00:00, alextretyak          #25 

    uint8_t read_byte()
    {
        return buffer[buffer_pos++];
    }

    uint8_t read_byte()
    {
        uint8_t result = buffer[buffer_pos];
        ++buffer_pos;
        return result;
    }

..., а свойство таких операций выполнять действие над операндом по окончании всех остальных операций.

template <typename T> T operator++(T& a, int)
{
    T temp = a; // для типа `T` должен быть определён конструктор копирования
    ++a;        // для типа `T` должен быть определён префиксный оператор `++`
    return temp;
}
// и аналогично для `--`

• поведение постфиксных операций становится полностью детерминированным: выражение a++ − a++ всегда возвращает -1 и при этом увеличивает a на 2; правда при условии, что компилятор при расчёте разности вычисляет уменьшаемое (левый операнд) всегда перед вычитаемым (правый операнд);
• исчезает различие в поведении постфиксных операций для встроенных в язык типов (int, float и др. — для них «++» и «--» выполняются после выполнения всего выражения) и для пользовательских типов (для них применяются переопределённые постфиксные «++» и «--»);
• пропадает «магия» в виде дополнительного неиспользуемого аргумента при переопределении операций «++» и «--», т.к. программист вообще не может переопределить постфиксные «++» и «--», а только префиксные (постфиксные всегда генерируются компилятором автоматически);
• это упрощает реализацию, т.к. запись a++ компилятор может просто заменять на вызов служебной функции postfix_increment(a), которая реализована аналогично:

template <typename T> T postfix_increment(T& a)
{
    T temp = a;
    ++a;
    return temp;
}

✅  2024/03/27 08:01, kiv          #26 

✅  2024/03/27 16:08, Автор сайта          #27 

постарайтесь исключить Си из своих инструментов и перестаньте обсуждать его достоинства и недостатки.

do { *dst++ = *src++;} while (*src);

В следующем примере переменная изменяется трижды между точками следования, что приводит к неопределённому результату:

int i = 1;    // Описатель - первая точка следования, полное выражение - вторая
i += ++i + 1; // Полное выражение - третья точка следования
printf("%d\n", i); // Может быть выведено как 4, так и 5

Другие простые примеры неопределённого поведения, которого необходимо избегать:

i = i++ + 1; // неопределённое поведение
i = ++i + 1; // тоже неопределённое поведение

printf("%d, %d\n", --i, ++i); // неопределённое поведение
printf("%d, %d\n", ++i, ++i); // тоже неопределённое поведение

printf("%d, %d\n", i = 0, i = 1); // неопределённое поведение
printf("%d, %d\n", i = 0, i = 0); // тоже неопределённое поведение

a[i] = i++; // неопределённое поведение
a[i++] = i; // тоже неопределённое поведение

✅  2024/03/27 19:12, MihalNik          #28 

избавить язык от всех постфиксных операций, от этого упрощается синтаксис языка

изменение какого-либо значения в одном флаконе с его использованием в качестве аргумента не есть хорошо

Если отказаться от постфиксного инкремента, тогда придётся этот метод переписать так

✅  2024/04/01 14:10, veector          #29 

И всё-таки, иногда постфиксные операции значительно удобнее. Вот у меня есть такой метод в классе:

    uint8_t read_byte()
    {
        return buffer[buffer_pos++];
    }

✅  2024/04/01 14:27, veector          #30 

Есть ещё один "крамольный" вариант — разрешить операторы после "return", тогда строки будет две, а не три, без лишних переменных. А return можно переименовать в result.

✅  2024/04/02 00:11, Автор сайта          #31 

buffer_pos++

разрешить операторы после "return", тогда строки будет две, а не три, без лишних переменных.

✅  2024/04/04 00:00, alextretyak          #32 

Есть ещё один "крамольный" вариант — разрешить операторы после "return", тогда строки будет две, а не три, без лишних переменных. А return можно переименовать в result.

Если buffer_pos локальная

Если она глобальная, то смысл увеличения есть, но есть резонный вопрос — зачем она глобальная?!

то сразу выдаю минус в карму.

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

✅  2024/04/05 12:36, veector          #33 

✅  2024/04/07 00:00, alextretyak          #34 

всегда, всем, все разъясняю.

✅  2024/04/08 17:52, veector          #35 

✅  2024/04/08 23:43, Автор сайта          #36 

✅  2024/04/10 00:00, alextretyak          #37 

Вы же считываете значение из массива, 1 байт, не проверяя номер элемента.

    uint8_t read_byte()
    {
        if (at_eof())
            throw UnexpectedEOF();
        return buffer[buffer_pos++];
    }

    uint8_t read_byte()
    {
        return !at_eof() ? buffer[buffer_pos++] : throw UnexpectedEOF();
    }

поделитесь тайным знанием, почему ваши сообщения в последнее время всегда делаются в 00:00

✅  2024/04/10 17:55, veector          #38 

 do { *dst++ = *src++;} while (*src);

 do { *dst = *src; dst++; src++; ) while (*src);

Но возвращаясь к теме статьи: против использования постфиксного инкремента в теле метода read_byte() вы ничего не имеете?

// Простите, но я люблю Си, поэтому, будет чистый Си, а в C++ вы уж сами переведете.
bool stream_get_byte(stream_t *stream, uint8_t *byte_ptr);
int stream_get_byte(stream_t *stream);
// + #define STREAM_EMPTY (-1), результат вне кодировки байта.

// К буферам это всё тоже применимо и тоже использую:
bool buffer_get_byte(buffer_t *buffer, uint8_t *byte_ptr);
int buffer_get_byte(buffer_t *buffer);
// + #define BUFFER_EMPTY (-1), результат вне кодировки байта.

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

✅  2024/04/11 00:08, Автор сайта          #39 

Ах, вот оно в чём дело.

Уже более 4-х с половиной лет

если ... отложить их отправку/публикацию ... и периодически перечитывать текст перед отправкой, то качество сообщений при этом повышается.

наличие в тексте программы исключений и ассертов рантайма, для меня это признаки плохо спроектированной программы.

✅  2024/04/21 00:00, alextretyak          #40 

Так исторически сложилось, что я больше пишу на Си с применением парадигмы ООП и мне ни разу не потребовалось применять исключения ни в одном крупном проекте.

Вместо чтения read_byte() и буфера я использую другие методы и понятия: поток и извлечение информации из потока.

    int lines_count = 0;
    int fd = open("input.txt", O_RDONLY | O_BINARY);
    bool cr = false;
    static char buffer[32*1024];
    while (true) {
        int n = read(fd, buffer, sizeof(buffer));
        if (n <= 0) break;

        if (cr && buffer[0] == '\n')
            lines_count++;

        for (int i = 1; i < n; i++)
            if (buffer[i] == '\n' && buffer[i-1] == '\r')
                lines_count++;

        cr = buffer[n-1] == '\r';
    }
    std::cout << lines_count << '\n'; // или printf("%i\n", lines_count);

    int lines_count = 0;
    IFile f("input.txt");               // FILE *f = fopen("input.txt", "rb");
    char prevc = 0;                     // char prevc = 0, c;
    while (!f.at_eof()) {               // while ((c = fgetc(f)) != EOF) {
        char c = (char)f.read_byte();   // (в этой строке будет пусто)
        if (c == '\n' && prevc == '\r')
            lines_count++;
        prevc = c;
    }
    std::cout << lines_count << '\n';

считаю, что в теле метода read_byte() в виде buffer[buffer_pos++] он [постфиксный инкремент] неуместен

int buffered_stream_get_byte(buffered_stream_t *stream)
{
    if (buffered_stream_is_empty(stream))
        return STREAM_EMPTY;
    return stream->buffer[stream->buffer_pos++];
}

✅  2024/07/08 16:15, veector          #41 

Здесь вы также считаете неуместным использование постфиксного инкремента?

Тогда какой код был бы лучше в данном случае?

int buffered_stream_get_byte(buffered_stream_t *stream, int default_value)
{
    int result = default_value;
    
    if (!buffered_stream_is_empty(stream))
    {
        result = stream->buffer[stream->buffer_pos];
        stream->buffer_pos++;
    };

    return result;
}

✅  2024/07/08 16:23, Gudleifr          #42 

Но оптимизация это все-таки не про сокращение числа строчек в программе... а про ООП, информационные модели, интересные приемы и архитектурные решения

ошибка, а конструкции ... провоцируют программиста их совершать

✅  2024/07/08 16:33, veector          #43 

Я модифицировал вашу краткую функцию вот таким образом

✅  2024/07/08 16:36, veector          #44 

✅  2024/07/08 16:50, Gudleifr          #45 

если не секрет

✅  2024/07/08 16:56, veector          #46 

✅  2024/07/29 00:00, alextretyak          #47 

Код программы — это же не константа, он постепенно изменяется.

Обращение за пределы памяти переменной это достаточно частая ошибка, а конструкции вида stream->buffer[stream->buffer_pos++] провоцируют программиста их совершать.

Сейчас нам надо вернуть один байт, а условно "завтра" попросят вернуть int

return *b++;

return cur++;

✅  2024/07/29 11:35, Gudleifr          #48 

Я сейчас пишу статью, посвящённую сравнению моделей итераторов в различных языках программирования

✅  2024/07/29 17:44, DEAD CODE          #49 

Лучше напишите "Об общей ошибочности концепции языков, требующих итераторов".

✅  2024/07/29 18:20, Gudleifr          #50 

Не хочется самому это написать?

✅  2024/08/03 14:53, Автор сайта          #51 

все обращения к недействительной памяти должны отслеживаться и не допускаться на уровне языка программирования

пишу статью, посвящённую сравнению моделей итераторов в различных языках программирования.

чтобы сдвинуть этот форум с мертвой точки

✅  2024/08/03 15:07, Gudleifr          #52 

вбил по очереди в поиск оба Ваших вопроса

✅  2024/08/12 15:17, Вежливый Лис          #53 

компилятор у вас не получится

✅  2024/08/12 21:49, Автор сайта          #54 

✅  2024/08/14 10:31, veector          #55 

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

Если постоянно переделывать фундамент, то постройка дома так никогда и не завершится.

Взять к примеру недавний случай со сбоем CrowdStrike... Драйверы — это не прикладное ПО. К ним вполне применим принцип «работает — не трогай».

✅  2024/08/14 10:38, veector          #56 

все обращения к недействительной памяти должны отслеживаться и не допускаться на уровне языка программирования

Согласен, тоже обращал на это внимание.

✅  2024/09/02 00:00, alextretyak          #57 

Если не трудно, дайте ссылку по мере готовности.

✅  2024/09/02 22:24, Автор сайта          #58 

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su