Почему у нас есть постфиксный прирост?

Отказ от ответственности : я прекрасно знаю семантику приращения префикса и постфикса. Поэтому, пожалуйста, не объясните мне, как они работают.

Читая вопросы о переполнении стека, я не могу не заметить, что программисты путаются с оператором приращения postfix снова и снова. Отсюда вытекает следующий вопрос: есть ли случай использования, когда приращение постфикса дает реальную выгоду с точки зрения качества кода?

Позвольте мне уточнить мой вопрос на примере. Вот краткая реализация strcpy:

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

Но это не совсем самодокументируемый код в моей книге (и он вызывает два раздражающих предупреждения на здравомыслящих компиляторах). Так что не так со следующей альтернативой?

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

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

while (*src != '\0')
{
    *dst = *src;
    ++src;
    ++dst;
}
*dst = '\0';

(Да, я знаю, srcи dstв этих альтернативных решениях будут разные конечные значения, но, поскольку strcpyсразу возвращается после цикла, в этом случае это не имеет значения.)

Кажется, цель постфиксного приращения - сделать код максимально кратким. Я просто не понимаю, к чему мы должны стремиться. Если это изначально было связано с производительностью, то все еще актуально сегодня?

Хотя это когда-то сказывалось на производительности, я думаю, что настоящая причина в том, чтобы четко выразить свои намерения. Реальный вопрос в том, while (*d++=*s++);ясно ли выражает намерение что-то или нет. ИМО, так и есть, и я считаю, что альтернативы, которые вы предлагаете, менее ясны - но это может (легко) быть результатом того, что потратили десятилетия, привыкнув к тому, как все делается. Научившись C от K & R (потому что было почти нет других книг по C в то время) , вероятно , тоже помогает.

В некоторой степени это правда, что краткость была оценена в гораздо большей степени в старом коде. Лично я думаю, что это было в значительной степени хорошо - понимание нескольких строк кода обычно тривиально; что трудно понять большие куски кода. Тесты и исследования неоднократно показали, что установка всего кода на экране одновременно является основным фактором в понимании кода. По мере расширения экранов это, похоже, остается верным, поэтому сохранение кода (разумно) кратким остается ценным.

Конечно, можно пойти за борт, но я не думаю, что это так. В частности, я думаю, что это становится слишком сложным, когда понимание одной строки кода становится чрезвычайно трудным или трудоемким, особенно когда понимание меньшего количества строк кода требует больше усилий, чем понимания большего количества строк. Это часто встречается в Лиспе и APL, но, кажется, (по крайней мере, мне) это не так.

Меня меньше беспокоят предупреждения компилятора - по моему опыту, многие компиляторы выдают совершенно нелепые предупреждения на довольно регулярной основе. Хотя я, конечно, думаю, что люди должны понимать свой код (и любые предупреждения, которые он может выдавать), приличный код, который может вызвать предупреждение в каком-то компиляторе, не обязательно ошибочен. По общему признанию, новички не всегда знают то, что они могут безопасно проигнорировать, но мы не останемся новичками навсегда, и нам также не нужно кодировать, как мы.

Это было, аппаратная вещь

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

Хотя C разрабатывался на различных ранних и слабых машинах, C и Unix впервые достигли сравнительно большого успеха с моделями PDP-11 с управлением памятью. В свое время это были относительно важные компьютеры, и Unix был намного лучше - экспоненциально лучше - чем другие 7 отвратительных операционных систем, доступных для -11.

И так случилось, что на PDP-11,

*--p

а также

*p++

... были реализованы на аппаратном уровне в качестве режимов адресации. (Кроме того *p, но никакой другой комбинации.) На этих ранних машинах, на частотах менее 0,001 ГГц сохранение одной или двух инструкций в цикле должно было почти подождать секунду, подождать минуту или выйти из строя. -обеденная разница Это конкретно не относится к постинкременту, но цикл с указателем постинкремента мог бы быть намного лучше, чем индексирование в то время.

Как следствие, шаблоны проектирования, потому что C идиомы, которые стали C психическими макросами.

Это что-то вроде объявления переменных сразу после {... не с тех пор, как C89 был текущим, это было требованием, но теперь это шаблон кода.

Обновление: очевидно, что основная причина *p++в языке заключается в том, что это именно то, что так часто хотят делать. Популярность шаблона кода была подкреплена популярным аппаратным обеспечением, которое соответствовало уже существующему шаблону языка, разработанного немного до появления PDP-11.

В наши дни это не имеет значения , какой шаблон вы используете, или если вы используете индексацию, и мы обычно программы на более высоком уровне , в любом случае, но оно должно иметь значения много на этих 0.001GHz машинах, и используя ничего, кроме *--xили *x++означало бы вас не «достали» PDP-11, и к вам могли бы подойти люди и сказать «знаете ли вы, что…» :-) :-)

Префикс, постфикс --и ++операторы были введены на языке B (предшественник C) Кеном Томпсоном - и нет, они не были вдохновлены PDP-11, которого в то время не существовало.

Цитата из "Развитие языка Си" Деннис Ритчи :

Томпсон пошел дальше, изобретая ++и--операторы, которые увеличивают или уменьшают; их позиция префикса или постфикса определяет, происходит ли изменение до или после указания значения операнда. Они не были в самых ранних версиях B, но появились по пути. Люди часто предполагают, что они были созданы, чтобы использовать режимы адреса с автоматическим увеличением и автоматическим уменьшением, предоставляемые DEC PDP-11, в которых C и Unix впервые стали популярными. Это исторически невозможно, так как при разработке B не было PDP-11. PDP-7, однако, имел несколько ячеек памяти с «автоинкрементом» со свойством, что косвенная ссылка на память через них увеличивала ячейку. Эта особенность, вероятно, предложила Томпсону такие операторы; обобщение, чтобы сделать их префиксом и постфиксом, было его собственным. На самом деле,++xбыл меньше, чем у x=x+1.

Очевидная причина существования оператора postincrement заключается в том, что вам не нужно писать выражения наподобие (++x,x-1)или (x+=1,x-1)повсеместно или бесполезно разделять тривиальные операторы с понятными побочными эффектами на несколько операторов. Вот некоторые примеры:

while (*s) x+=*s++-'0';

if (x) *s++='.';

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

Изменить: На самом деле это не было бы так ужасно; вместо (++x,x-1)вас, конечно, можно использовать ++x-1или (x+=1)-1. Все x++еще более читабельно.

PDP-11 предлагал операции пост-инкремента и пре-декремента в наборе команд. Теперь это не были инструкции. Это были модификаторы команд, которые позволяли вам указать, что вы хотите получить значение регистра до его увеличения или уменьшения.

Вот шаг копирования текста на машинном языке:

movw (r1)++,(r2)++

который переместил слово из одного места в другое, на которое указывают регистры, и регистры были бы готовы сделать это снова.

Поскольку C был построен на и для PDP-11, многие полезные концепции нашли свое отражение в C. C должен был стать полезной заменой языку ассемблера. Предварительное увеличение и последующее уменьшение были добавлены для симметрии.

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

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

Это вроде как & и | оператор с более низким приоритетом, чем ==

Он был разработан с благими намерениями (не короткая замыкательная версия && и ||), но теперь он смущает программистов каждый день и, вероятно, никогда не изменится.

В любом случае, это всего лишь ответ, потому что я думаю, что нет хорошего ответа на ваш вопрос, но я, вероятно, ошибаюсь, если я буду более опытным программистом, чем я.

--РЕДАКТИРОВАТЬ--

Должен заметить, что я считаю, что оба они невероятно полезны, я просто указываю, что это не изменится, нравится это кому-то или нет.

Мне нравится постфиксный оператор при работе с указателями (независимо от того, разыменую я их или нет), потому что

p++

читается более естественно, как «перейти к следующему месту», чем эквивалент

p += 1

что, безусловно, должно смутить начинающих, когда они впервые увидят, что он используется с указателем, где sizeof (* p)! = 1.

Вы уверены, что правильно заявляете о проблеме путаницы? Новичков не смущает тот факт, что оператор postfix ++ имеет более высокий приоритет, чем оператор разыменования *, так что

*p++

разбирает как

*(p++)

и нет

(*p)++

как некоторые могут ожидать?

(Вы думаете, что это плохо? См. Чтение объявлений C ).

Среди тонких элементов хорошего программирования - локализация и минимализм :

• положить переменные в минимальном объеме использования
• использование const, когда доступ для записи не требуется
• и т.п.

В том же духе x++это можно рассматривать как способ локализации ссылки на текущее значение, при xэтом сразу указав, что вы - по крайней мере, на данный момент - закончили с этим значением и хотите перейти к следующему (допустимо, xявляется ли intили указатель или итератор). Приложив немного воображения, вы можете сравнить это с тем, чтобы позволить старому значению / позиции xвыйти из области видимости сразу после того, как оно больше не требуется, и перейти к новому значению. Точная точка, в которой возможен этот переход, выделяется постфиксом++ . Подразумевается, что это, вероятно, конечное использование «старого», xможет быть полезным для понимания алгоритма, помогая программисту сканировать окружающий код. Конечно, постфикс++ может заставить программиста искать использование нового значения, которое может или не может быть хорошим в зависимости от того, когда это новое значение действительно необходимо, так что это аспект "искусства" или "ремесла" программирования, чтобы определить, что более важно полезно в данных обстоятельствах.

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

Ух ты, много ответов не совсем по теме (если я могу быть настолько смелым), и, пожалуйста, прости меня, если я указываю на очевидное - особенно в свете твоего комментария, чтобы не указывать на семантику, но на очевидное (с точки зрения Страуструпа, я полагаю) еще не опубликовано! :)

Postfix x++создает временное выражение, которое передается «вверх» в выражении, а переменная xвпоследствии увеличивается.

Префикс ++xне создает временный объект, но увеличивает «x» и передает результат в выражение.

Значение - удобство для тех, кто знает оператора.

Например:

int x = 1;
foo(x++); // == foo(1)
// x == 2: true

x = 1;
foo(++x); // == foo(2)
// x == 2: true

Конечно, результаты этого примера могут быть получены из другого эквивалентного (и, возможно, менее косого) кода.

Так почему у нас есть постфиксный оператор? Я думаю, потому что это идиома, которая сохраняется, несмотря на путаницу, которую она, очевидно, создает. Это унаследованная конструкция, которая когда-то воспринималась как имеющая ценность, хотя я не уверен, что воспринимаемая ценность была столько же для производительности, сколько для удобства. Это удобство не было потеряно, но я думаю, что оценка удобочитаемости увеличилась, что привело к сомнению цели оператора.

Нужен ли нам постфиксный оператор? Скорее всего нет. Его результат сбивает с толку и создает барьер для понимания. Некоторые хорошие программисты, безусловно, сразу узнают, где найти его полезным, часто в тех местах, где он имеет своеобразную «PERL-esque» красоту. Стоимость этой красоты - читабельность.

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

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

Другими словами, некоторые люди находят, while (*dst++ = *src++);что это просто более красивое решение, которое захватывает ваше дыхание своей простотой, точно так же, как если бы оно было кистью на холсте. То, что вы вынуждены понимать язык, ценить красоту, только добавляет к ее великолепию.

Давайте посмотрим на оригинальное обоснование Kernighan & Ritchie (оригинальные K & R стр. 42 и 43):

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

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

Три приведенных примера ( squeeze(), getline()и strcat()) используют только постфикс в выражениях, использующих индексацию. Авторы сравнивают код с более длинной версией, которая не использует встроенные приращения. Это подтверждает, что основное внимание уделяется компактности.

На странице 102 выделено K & R, использование этих операторов в сочетании с разыменованием указателей (например, *--pи *p--). Дальнейшего примера не приводится, но опять же, они ясно дают понять, что выгода заключается в компактности.

Например, префикс очень часто используется при уменьшении индекса или указателя, начиная с конца.

 int i=0; 
 while (i<10) 
     doit (i++);  // calls function for 0 to 9  
                  // i is 10 at this stage
 while (--i >=0) 
     doit (i);    // calls function from 9 to 0 

Я буду не согласен с утверждением о том , что ++p, p++, каким - то образом трудно читать или неясными. Один означает «увеличить p и затем прочитать p», другой означает «прочитать p и затем увеличить p». В обоих случаях оператор в коде находится именно там, где он находится в объяснении кода, поэтому, если вы знаете, что ++означает, вы знаете, что означает результирующий код.

Вы можете создать обфусцированный код, используя любой синтаксис, но я не вижу здесь случая, который p++/ ++pявляется по своей сути запутанным.

это от POV электротехника:

Есть много процессоров, которые имеют встроенные операторы пост-инкремента и пре-декремента для поддержки стека «последний пришел-первым вышел» (LIFO).

это может быть как:

 float stack[4096];
 int stack_pointer = 0;

 ... 

 #define push_stack(arg) stack[stack_pointer++] = arg;
 #define pop_stack(arg) arg = stack[--stack_pointer];

 ...

я не знаю, но по этой причине я ожидал увидеть префиксные и постфиксные операторы приращения.

Чтобы подчеркнуть точку зрения Кристофа о компактности, я хочу показать вам немного кода из V6. Это часть оригинального компилятора C, http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/c00.c :

/*
 * Look up the identifier in symbuf in the symbol table.
 * If it hashes to the same spot as a keyword, try the keyword table
 * first.  An initial "." is ignored in the hash.
 * Return is a ptr to the symbol table entry.
 */
lookup()
{
    int ihash;
    register struct hshtab *rp;
    register char *sp, *np;

    ihash = 0;
    sp = symbuf;
    if (*sp=='.')
        sp++;
    while (sp<symbuf+ncps)
        ihash =+ *sp++;
    rp = &hshtab[ihash%hshsiz];
    if (rp->hflag&FKEYW)
        if (findkw())
            return(KEYW);
    while (*(np = rp->name)) {
        for (sp=symbuf; sp<symbuf+ncps;)
            if (*np++ != *sp++)
                goto no;
        csym = rp;
        return(NAME);
    no:
        if (++rp >= &hshtab[hshsiz])
            rp = hshtab;
    }
    if(++hshused >= hshsiz) {
        error("Symbol table overflow");
        exit(1);
    }
    rp->hclass = 0;
    rp->htype = 0;
    rp->hoffset = 0;
    rp->dimp = 0;
    rp->hflag =| xdflg;
    sp = symbuf;
    for (np=rp->name; sp<symbuf+ncps;)
        *np++ = *sp++;
    csym = rp;
    return(NAME);
}

Это код, который был распространен в самиздате как хорошее образование, и тем не менее мы бы никогда не написали его сегодня. Посмотрите , как много побочных эффектов , которые были упакованы в ifи whileусловие, и , наоборот, как оба forпетель не имеет приращение выражения , так как это сделано в теле цикла. Посмотрите, как блоки заключаются в фигурные скобки, только когда это абсолютно необходимо.

Частично это была, конечно, ручная микрооптимизация, подобная той, которую мы ожидаем, что компилятор сделает для нас сегодня, но я бы также выдвинул гипотезу о том, что, когда весь ваш интерфейс к компьютеру представляет собой один стеклянный tty 80x25, вам нужен код быть настолько плотным, насколько это возможно, чтобы вы могли видеть больше этого одновременно.

(Использование глобальных буферов для всего - это, вероятно, похмелье от перерезания зубов на ассемблере.)

Возможно, вам стоит подумать и о косметике.

while( i++ )

возможно, "выглядит лучше", чем

while( i+=1 )

По какой-то причине оператор постинкремента выглядит очень привлекательно. Он короткий, сладкий, и все увеличивается на 1. Сравните это с префиксом:

while( ++i )

"оглядывается назад" не так ли? Вы никогда не увидите знак «плюс» в математике, за исключением случаев, когда кто-то глупо указывает что-то положительное ( +0или что-то в этом роде). Мы привыкли видеть ОБЪЕКТ + ЧТО-ТО

Это как-то связано с оценкой? А, А +, А ++? Я могу сказать вам, что сначала я был довольно сыром, что люди operator++из Python удалили свой язык!

Считая от 9 до 0 включительно:

for (unsigned int i=10; i-- > 0;)  {
    cout << i << " ";
}

Или эквивалентный цикл while.