C для цикла реализован иначе, чем в других языках?

Он, вероятно, имеет в виду циклы for, такие как for i:=0 to N, и циклы for-each, которые перебирают элементы набора. Я подозреваю, что все языки, в которых есть цикл for в стиле C, на самом деле получили его от C.

Учти это:

for i:=0 to 100 do { ... }

В этом случае мы могли бы заменить окончательное значение 100 вызовом функции:

for i:=0 to final_value() do { ... }

... и функция final_value вызывается только один раз.

Однако в C:

for (int i=0; i<final_value(); ++i) // ...

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

int end = final_value();
for (int i=0; i<end; ++i) // ...

Возможно, петля разворачивается? Если вы знаете, сколько раз будет выполняться цикл for, вы можете буквально скопировать и вставить содержимое цикла. Большинство циклов while будут основаны на каком-то условии, которое не является простым подсчетом от 0 до N, поэтому эту оптимизацию нельзя будет использовать.

Возьмите этот пример

int x;
for (x = 10; x != 0; --x)
{
    printf ("Hello\n");
}

Я знаю, что вы обычно делаете x = 0; x <= 10; ++x, но все это будет раскрыто в сборке.

какая-то псевдосборка:

mov 10, eax
loop:
print "hello"
dec eax
jne loop

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

Если бы мы развернули его, мы могли бы просто положить

print "hello"
print "hello"
print "hello"
print "hello"
print "hello"
print "hello"
print "hello"
print "hello"
print "hello"
print "hello"

Никакие другие инструкции нам не понадобятся, так что это быстрее. Это всего лишь простой пример - я постараюсь найти лучший!

Магнус прав, но следует также отметить, что в большинстве языков (pre-C) условным условием является критерий конец (т.е. «остановить, когда i равно 100»). В C (и большинстве языков post-C) это критерий Продолжать (т. Е. «Продолжать, пока i меньше 100»).

По сути, цикл for C (а также Java, JavaScript и множество языков, производных от C) действительно является синтаксическим сахаром для цикла while:

for (int i = 0; i < max; i++) { DoStuff(); }

которая является очень актуальной идиомой, строго эквивалентна:

int i = 0; while (i < max) { DoStuff(); i++; }

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

Условие остановки оценивается на каждой итерации. В некоторых случаях это может быть интересно, но может быть ловушкой: я видел i < strlen(longConstantString) в источнике, что является основным способом замедлить работу программы, потому что strlen - дорогостоящая функция в C.
. Каким-то образом цикл for в основном предназначен для запуска несколько раз, о чем известно заранее, вы все равно можете использовать break для раннего завершения, поэтому динамическая оценка условия остановки больше раздражает, чем полезна: если вам действительно нужна динамическая оценка, вы используете while () {} (или do {} while ()).

На некоторых других языках, таких как Lua, условие остановки оценивается только один раз, при инициализации цикла. Это помогает прогнозировать поведение цикла и часто более производительно.

В x86 цикл for может быть выполнен на уровне сборки без создания цикла while. Команда петля уменьшает значение регистра ecx и переходит к операнду, если ecx больше 0, в противном случае она ничего не делает. Это классический цикл for.

mov ecx, 0x00000010h
loop_start:
;loop body
loop loop_start
;end of loop

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

for (i=0; i<100; i++) dostuff();

будет хорошо, и компилятор может его оптимизировать.

Если вы используете функцию в части continue оператора for, например

for (i=0; i<strlen(s); i++) dostuff();

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

Если возвращаемое значение функции не изменится во время итерации, извлеките его из цикла:

slen = strlen(s);
for (i=0; i<slen; i++) dostuff();

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

for (isread(fd, &buffer, ISFIRST);
     isstat(fd) >= 0;
     isread(fd, &buffer, ISNEXT)
{
  dostuff(buffer);
}

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

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

Последний пример можно было бы выразить в виде цикла while:

isread(fd, &buffer, ISFIRST);
while (isstat(fd) >= 0)
{
  dostuff(buffer);
  isread(fd, &buffer, ISNEXT);
}

но это не так аккуратно, и если я использую continue в цикле, мне придется снова вызвать итерацию isread. Помещение всего этого в цикл for делает его более аккуратным и гарантирует, что итерация isread вызывается каждым циклом.

Я пишу функции нижнего уровня, чтобы их можно было использовать в таких циклах for. Он объединяет все элементы цикла while, чтобы вам было легче понять его.

В Аде (и я считаю, что в большинстве других языков, производных от Алгола) условие завершения цикла for оценивается только один раз, в начале цикла. Например, предположим, что у вас есть следующий код на Аде

q := 10;
for i in 1..q loop
    q := 20;
    --// Do some stuff
end loop;

Этот цикл будет повторяться ровно 10 раз, потому что q было 10 при запуске цикла. Однако, если я напишу, казалось бы, эквивалентный цикл на C:

q = 10;
for (int i=0;i<q;i++) {
   q = 20;
   // Do some stuff
}

Затем цикл повторяется 20 раз, потому что q было изменено на 20 к тому времени, когда я стал достаточно большим, чтобы это имело значение.

Конечно, способ C более гибкий. Однако это имеет ряд негативных последствий. Очевидно, что программе приходится тратить усилия на повторную проверку состояния цикла каждый цикл. Хороший оптимизатор может быть достаточно умен, чтобы обойти проблему в простых случаях, подобных этому, но что произойдет, если «q» является глобальным и «сделать что-нибудь» включает вызов процедуры (и, таким образом, теоретически может изменить q)?

Сложный факт в том, что мы просто знаем путь о цикле Ada больше, чем о цикле C. Это означает, что при том же уровне интеллекта и усилий в оптимизаторе Ada может намного лучше выполнять работу по оптимизации. Например, компилятор Ada знает, что он может заменить весь цикл 10 копиями содержимого, независимо от того, что это за содержимое. Оптимизатор C должен будет изучить и проанализировать содержимое.

На самом деле это лишь один из многих способов, при которых дизайн синтаксиса C поджимает компилятор.

Возможно, Кнут имеет в виду БЕЙСИК.

В BASIC (старом, про VB не знаю) циклы FOR были реализованы по-другому.

Например. перебрать десять раз

ДЛЯ N = от 1 до 10

...

СЛЕДУЮЩИЙ N

---- ИЛИ ЖЕ ---- найти сумму четных чисел меньше 100

ДЛЯ N = 0 ДО 100 ШАГ 2

...

СЛЕДУЮЩИЙ N

В C у вас может быть любое условие в "for" для проверки выхода из цикла. Думаю, более гибкая.

Чего эти пуристы, кажется, никогда не осознают, так это всей суть C, и, в некоторой степени, C++ дает возможность реализовать то, что вы хотите и как вы этого хотите. По общему признанию, если результат вашего конечного выражения изменится, было бы лучше просто использовать цикл while. Возможно, проблема в том, что у программистов создается впечатление, что C реализует "высокий уровень", но каждый должен знать, что C - это довольно низкоуровневый язык.

The very 'practicality' means that the would-be CS major has to learn Kernighan's mistakes in designing C, notably the infamous fact that a for loop evaluates the for condition repeatedly, which duplicates while and fails to match the behavior of most other languages which implement a for loop.

Муаахахаха!

Мне нравятся основные (каламбурные) утверждения рецензента:

• Ошибки Кернигана
• печально известный факт
• не соответствует поведению большинства других языков

Для меня это пахнет кем-то, кому так и не удалось овладеть основными функциями / философией C.

Введение

Поскольку я все еще изучал физику в университете, я обнаружил, что C (то есть C-подобные языки) должны стать моим предпочтительным языком, когда я обнаружил цикл C для.

Таким образом, очевидно, что неудача одного стиля - это успех другого стиля. На этом субъективная часть обсуждения закончится.

Возможно, for Кернигана следовало называть циклом?

Просто шучу? Возможно нет.

Автор обзора, по-видимому, решил, что каждая языковая конструкция должна вести себя одинаково в разных языках. Так что переименование для в петля облегчило бы его / ее дискомфорт.

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

Действительно ли C нужен?

Цитируя автора обзора, он делает следующие утверждения о для и пока:

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

Наличие ортогональных элементов - это хорошо, когда их можно комбинировать. Но на всех языках, которые я знаю, невозможно объединить для и пока вместе.

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

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

Заключение

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

Цитата Бьярна Страуструпа:

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Так что в целом комментарий рецензента следует рассматривать как похвалу.

^ _ ^