Сишные циклы FOR в Паскаль не переводятся?

← →
Думкин © (2006-12-24 07:06) [160]

> AM (24.12.06 04:14) [150]
> Думкин пишет "оптимальности Паскалевского Фор в Си нет".

Да, я написал эту фразу. Подразумевал, бееспорно конструкцию вида:
for(i=0;i<f(n);i++)
Если приведенное вами, закрывает это также как и в Паскале - что ж, в этом пункте был неправ. И Сишный фор - это ходячий монстр. :)

← →
Step by step (2006-12-24 07:06) [161]

> ors_archangel © (24.12.06 06:56) [159]
> твой пример, согласись, довольно искусственный.

Циклы с шагами понадобились тебе. Так, что искусственность - твоя.

← →
Step by step (2006-12-24 07:15) [162]

> ors_archangel © (24.12.06 06:56) [159]
> Знаешь, если развить твою мысль, то лучше при упоминании
> переменной сразу же писать её тип, чтобы не "крутить туда-
> сюда" и не "устраивать конкурс"ы

Не волнуйся. Ошибёшься - компилятор поправит.

← →
ors_archangel © (2006-12-24 07:16) [163]

> Step by step (24.12.06 06:54) [158]

Поясни, please, как из [154] следует [158].
Так…

> movq mm0, [eax] pfadd mm0, [edx] movq [ecx], mm0 movq
> mm1, [eax+8]pfadd mm1, [edx+8]movq [ecx+8], mm1femms
>

переносим в регистр mm0 переменную 64 bit из [eax], честно говоря, не знаю, что такое pfadd (может просветишь?), … emms - очистка стека FPU

← →
Step by step (2006-12-24 07:23) [164]

3DNow! учи.
Это всего лишь сложение.

← →
ors_archangel © (2006-12-24 07:24) [165]

Step by step! может ты подумал, что я хочу эксплуатировать твой ник? :)))) Я понял твоё мнение насчёт контроля ошибок, но вот слушай, писал ты i*2, i*2, шаг у тебя = 2, так? и вдруг забыл :( вот блин, а компилятор не поправит - это ведь логическая ошибка, а не синтаксическая, а вот если бы ты написал for i := 1 to 10 step 2 (извини за избитый пример), то такое было бы уже невозможно, это что-то вроде контроля типов, только здесь мы контролируем шаг. Жду твои контраргументы :) Только не надо про "агрессивных ламеров", я их боюсь :))

← →
ors_archangel © (2006-12-24 07:26) [166]

> 3DNow! учи.

Обязательно! Пасибо за хинт.

← →
Думкин © (2006-12-24 07:26) [167]

> > AM (24.12.06 04:14) [150]

А что будет, если end изменится в теле цикла? Все-таки как ни крути - конструкции не эквиваленты. Или я опять ошибаюсь?

← →
Думкин © (2006-12-24 07:53) [168]

> > > AM (24.12.06 04:14) [150]

А вообще, чтобы понять о чем я - вы бы прочитали ту ссылку на ГеймДев.

Когда я туда ходил, там было 4 страницы. Сейчас прошел - уже 9.
Там даже на 9-й странице продолжают упорствовать:

- аналог for в Паскале: for (int i = 0; i <= 10; i++){}. + макросы -> 1-1 сопоставление.
http://www.gamedev.ru/flame/forum/?id=58865&page=9 129 пост.

И много чего еще, с неприкрытым уничижением Паскаля. Может вы и не согласитесь, но в войнах типа "Паскаль против Си" с участием на одной из сторон принимают только ламеры. Эта точка зрения неоднократно обсуждалась тут. Можете возражать. Так вот в тех 9 страницах присутствует именно и это.
При этом не у всех участников. Но у значительной части. А я и не утверждал иного.

Поэтому позвольте мне остаться при своем прежнем мнении.

← →
Anatoly Podgoretsky © (2006-12-24 12:48) [169]

> ors_archangel (24.12.2006 1:28:26) [146]

for со step это уже while

← →
Anatoly Podgoretsky © (2006-12-24 12:50) [170]

> ors_archangel (24.12.2006 1:31:27) [147]

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

← →
Anatoly Podgoretsky © (2006-12-24 12:56) [171]

> AM (24.12.2006 4:14:30) [150]

Передергиваешь однака, ты ввел дополнительную переменную, а вопрос то про

for (int i = 0, i < function_call(); ++i)

А то можно навводить кучу переменных и говорить про погоду на Гаваях

← →
Anatoly Podgoretsky © (2006-12-24 12:59) [172]

> Думкин (24.12.2006 7:26:47) [167]

А чего тут ошибаться, тут налицо передергивание карт.

← →
Думкин © (2006-12-24 13:08) [173]

> Anatoly Podgoretsky © (24.12.06 12:59) [172]

Понял. А то чуть не занервничал - народец то мирный. Я даже часть постов оттуда здесь и привести не могу - правила форума не позволяют.

← →
Anatoly Podgoretsky © (2006-12-24 13:20) [174]

> Думкин (24.12.2006 13:08:53) [173]

На РО напросишься :-)

← →
AM (2006-12-24 18:19) [175]

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

>Качество обсуждения там было именно тем, что я озвучил. Если вас - >задело, ну значит задело. Попробуйте исправится - чтобы не задевало.
А какие у вас претензии к качеству? Меня задела необоснованность (или я не понял, что вы имели ввиду под качеством)

>А АСМ я знал, судя по вашему настрою, еще тогда когда вы о стол башкой >стукались. Причем тут это?
Я младше вас на 7 лет, так что вы немного ошиблись :). Просто без знания АСМа говорит что-либо об оптимальности неправильно, по-моему, поэтому спросил.

>Если приведенное вами, закрывает это также как и в Паскале - что ж, в >этом пункте был неправ. И Сишный фор - это ходячий монстр. :)
В принципе, случаи типа List.Count даже в варианте "i < func-call()" компилятор может заменить единичным вызовом функции перед телом цикла и дальше сравнивать с полученным значением, НО только в том случае, если он уверен, что логика от этого не изменится (впрочем, данная оптимизация работает не всегда).

>Там даже на 9-й странице продолжают упорствовать
Ну, люди бывают разные :) Темы изначально были театром абсурда - сравнивать Фор в языках... Ну, ещё можно сравнить begin end и { }

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

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

Anatoly Podgoretsky
>Передергиваешь однака, ты ввел дополнительную переменную, а вопрос то >про for (int i = 0, i < function_call(); ++i)
Ну, когда вам предлагали реализовать Си Фор в Паскале, вы использовали Вайл и доп. переменную (правда, Си-программиты к ней придирались). В общем-то, какая разница как оно выглядит в языке? Главное, что такую вещь можно реализовать, а важность её не настолько большая, чтобы придираться к ещё большим мелочам, по-моему. Если на то пошло, то Си и Паскаль надо сравнивать с Лиспом.

← →
Vga © (2006-12-24 18:19) [176]

> [147] ors_archangel © (24.12.06 01:31)
> А ещё для так любимого Borland OOP, inline то ж ой как пригодился
> б, хотя размер exeшников и так очень уж крут и без того,
> может, в этом причина, не хотели, чтобы exeшники весили
> ещё больше, больше, ведь уже некуда? А причина здесь уже
> в языке

Не в языке, в библиотеке. AvL дает куда меньший по размерам код. И куда меньше возможностей. А GUI библиотеки для С++ типа Qt & wxWidgets дают ехе метров в 2-5.

> [170] Anatoly Podgoretsky © (24.12.06 12:50)

Не с винчестерами, канал до инета у таких "озабоенных" медленный и недешевый.

← →
Думкин © (2006-12-24 18:38) [177]

> AM (24.12.06 18:19) [175]

0. Одним постом не всегда получается.
1. Про качество описал ниже, что и вы заметили.
2. 7 лет иногда срок. :) Но асм я тут и не подразумевал. Я тут пункт 3-й подразумевал.
3. Компилятор и должен быть уверен. В Паскале он уверен в этом по сути самого фор. И только об этом собственно и речь.
4. Везде разные. Согласен. Тут тоже 9-я страница.
5. Я мало видел, чтобы наезжали на Си. Кроме синтаксиса и иногда трудночитаемости. Наезды же на Паскаль очень часты. И со стороны "Сионистов", так и из их подгруппы - игроделов. Причем зачастую они мало обоснованы и люди многие не в теме совершенно. Это увидел. Ведь многие посты дальше, "Гы, сына, лол" и не пошли. Там ведь даже ваш пример с введением переменной не приведен хотя бы. Впечатление, что люди не разобрались, а тут же пальцы веером. По этим впечатлением и написал свой пост. Провокаторов всяких хватает. Тут правы.
6. Входить в такие темы могут разные люди. И тут и там. Но вот принмать ту же позицию - вряд ли.

А зачем с Лиспом? Это уже другой подход и тип языка.

← →
AM (2006-12-24 21:51) [178]

2. Ага :) Я тут только-что посмотрел, за что его дают :)
3. Угу, это я и подразумевал под "условием работы фор".
5. Ну, тема была начата с "наезда" на Си и обсуждение там вели "Сионисты" и Флапс, поэтому на Си наезжал по мере сил только Флапс.
Про наезды я - согласен. Т.е., наезды есть (и на С++ тоже), но они или просто столь малозначительны, что не будут влиять на процесс написания программы, либо же предполагают использование несвойственных языку парадигм (ака притянутые за уши).
В принципе, те кто писали "Гы, сына, лол" в чем-то были правы (кстати, среди них затесалось пару звезд ГД :) ), ведь тема выеденного яйца не стоит, а разрослась на 9 страниц и, ещё, и алгоритмы умножения двоичных чисел затронула.
6. Просто на ГД меньше Дельфистов и вряд ли у них был шанс в такой огненной теме :)

Вообще, сравнение с Лиспом нечестное, конечно, но по синтаксическим возможностям такого рода он, по-моему, без проблем обходит Си и Паскаль.

← →
Cyrax © (2006-12-24 22:21) [179]

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

Ну а возражают тоже только ламеры (как бы пореще сформулировать...))?
C и Паскаль вполне можно обсуждать с точки зрения эффективности и удобства использования для каких-то определённых задач. Эти языки проектировались разными людьми и цели ставились разные...

← →
ors_archangel © (2006-12-25 01:00) [180]

> Anatoly Podgoretsky © (24.12.06 12:50) [170]
> Еще один озабоченный
> размерами испольнительными файлами, да что такого у вас
> с винчестерами творится, что такая головная боль?

Вы считаете, что KOLMCK - никому не нужная чушь на пустом месте, и люди, которые этим занимаются занимаются - просто "озабоченные размерами исполнительных файлов" и вам не понятно, "что такого у них с винчестерами творится, что такая головная боль"?

> Vga © (24.12.06 18:19) [176]
> Не в языке, в библиотеке

Не в библиотеке, а как она написана, --- все библиотеки, написанные на Делфи очень не эффективно статически компилируются в смысле всё тех же бедных мегабайтов, например, тот же KOL - это библиотека статической компановки для Делфи, но она написана, как подтверждает сам автор с нарушением концепций языка Delphi Language, покрайней мере, концепций ООП VCL уж точно, поэтому мы и имеем то, что имеем - сверх малый размер. В случае KOL и всех библиотек статической компоновки для Делфи вообще, всё дело уперается в две вещи: ВСЕ ВИРТУАЛЬНЫЕ МЕТОДЫ КЛАССА КОМПОНУЮТСЯ в не зависимости от надобности, в этом виноват компилятор Делфи, не язык, да, но и не библиотека, второе, это БЕЗУСЛОВНАЯ ИНИЦИАЛИЗАЦИЯ, например, в конструкторах классов, которая приводит к включению кода, которые нигде больше, кроме как в собственно инициализации не нужен, это уже проблема языка - он не разделяет обязательную и необязательную инициализацию объектов и переменных, вследствии чего компилятор тоже их не разделяет и в итоге инициализационный код из тех же секций initialization (да и finalization) тащит за собой порой совсем никому не нужные вещи :(
Дальше, если говорить о языке: посмотрм как Делфи "поддерживает" inline-функции:
• Inlining will not occur on any form of late-bound method. This includes virtual, dynamic, and message methods - совершенно не учитывается, что между override-методами одного класса всегда возможен inline • Routines containing assembly code will not be inlined. - запрещено в inline-функциях юзать асм, можно было обойтись ограничением на только поименнованный доступ к параметрам • If a routine is defined in the interface section and it accesses symbols defined in the implementation section, that routine cannot be inlined. - а что изменилось? получается, что львиная доля всех функций не подходит под инлайн, потому что для inline-функций нужен дополнительный линкинг, который компилятор конечно ну никак не может сделать • In Delphi.NET, routines in classes cannot be inlined if they access members with less (i.e. more restricted) visibility than the method itself. For example, if a public method accesses private symbols, it cannot be inlined. - то же самое • Procedures and functions used in conditional expressions in while-do and repeat-until statements cannot be expanded inline. - вообще ограничение без причины, как раз в циклах inline больше всего и нужен, странно, почему в forе ещё оставили • Within a unit, the body for an inline function should be defined before calls to the function are made. Otherwise, the body of the function, which is not known to the compiler when it reaches the call site, cannot be expanded inline. - доисторический однопроходный принцип :(
Т.о. видим, что Борланд сделал поддержку inline, НО при этом постеснялся качественно переработать компилятор, чтобы можно было просто поставить директиву inline, где требуется, нет: нужно сделать, чтобы метод был статическим и его тело было обязательно перед любым его использованием и т.д. Ещё одна конечно же не решённая Борландом проблема здесь - это перекомпиляция: если мы изменяем inline-функцию, то весь код юнитов, которые её используют, перекомпилируется, решение этой проблемы уже давно известно - пофункциональное связывание. О пользе inline тут уже понаписано, в том числе Sha, Борланду это как видим не особо надо, в Делфи много проблем с языком, но не вижу не одной проблемы, которая не имела бы достойного решения

> AM (24.12.06 18:19) [175]
> Си и Паскаль надо сравнивать с Лиспом.

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

← →
XProger © (2006-12-25 02:00) [181]

На GameDev достаточно Delphi"стов, это самый доброжелательный и рационально оценивающий ситуацию народ т.к. в спорах не пытается наговаривать на другой язык (за рядом исключений). Связано это конечно же с тем, что в отличии от сипиписьника боготворящего С++, дельфист-игрописатель должен владеть как Delphi так и С++...

ors_archangel,
Borland всячески мечтает отказаться от object и тянет его лишь в качестве обратной совместимости. Текущие record"ы уже обладают некоторой с ними схожестью (и даже больше). KOL как раз использует object и хранит указатели на них в качестве аналога наследования. Это не безопасно с точки зрения Delphi (именно поэтому появился class) да и не шибко удобно, но KOL"ом пользуются люди его понимающие, так что простительно... :)

inline реализован достаточно грамотно (во всяком случае, лучше чем ничего :) и требование static для метода ещё раз страхует тебя от ошибки (Delphi в этом - мастерица) или ты хотел виртуальный метод оборудовать inline вызовом? %) Думаешь если в C++ методу назначить inline - он 100% будет inlune? Щазззз... ты даже об этом не узнаешь )

← →
VEG © (2006-12-25 04:39) [182]

> Mystic © (18.12.06 08:44) [70]
> Противоречит стандарту, правильно:
> for(int i=0, j=30; i<j; ++i, --j)

Вроде как в цикле for не имеет значения, i++ или ++i. На порядок исполнения этой операции не влияет.

← →
Думкин © (2006-12-25 05:55) [183]

> Cyrax © (24.12.06 22:21) [179]

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

← →
Anatoly Podgoretsky © (2006-12-25 13:02) [184]

> ors_archangel (25.12.2006 1:00:00) [180]

> что KOLMCK - никому не нужная чушь на пустом месте

Не вкладывай свои мысли в мои уста. Это изуитский метод.

← →
Mystic © (2006-12-25 14:13) [185]

> Вроде как в цикле for не имеет значения, i++ или ++i. На
> порядок исполнения этой операции не влияет.

Я не про то. Писать ++i у меня вошло в привычку (в ряде случае компилятор сгенерирует более оптимальный код), но противоречие не в том. Код
for (int i = 0, int j = 30; i < j; i++, j--)
просто не скомпилируется рядом компиляторов (например gcc), потому что конструкция
int i=0, int j=0;
не является объявлением с точки зрения стандарта.

> ors_archangel © (25.12.06 01:00) [180]

Ты считаешь эти ограничения на inline принципиальными, а я нет. Хоть убей не вижу решающего выигрыша в производительности, если внутрь inline-а засунуть цикл while (затраты на CALL мизерны по сравнению с временем выполнения цикла) или от того, что вызов виртульного метода предка будет inline (ООП код априори не самый быстрый). И вообще в мире нет идеальных вещей :)

← →
J_f_S (2006-12-25 20:29) [186]

> Mystic © (25.12.06 14:13) [185]
> Код
> for (int i = 0, int j = 30; i < j; i++, j--)
> просто не скомпилируется рядом компиляторов (например gcc),
> потому что конструкция
> int i=0, int j=0;
> не является объявлением с точки зрения стандарта.

Ну, за гнус точно не скажу, но студия(.NET) ест без проблем.

← →
ANTPro © (2006-12-25 20:47) [187]

> [180] ors_archangel © (25.12.06 01:00)
> KOLMCK - никому не нужная чушь на пустом месте

: )

← →
Vga © (2006-12-25 21:46) [188]

> [180] ors_archangel © (25.12.06 01:00)
> > Vga © (24.12.06 18:19) [176]
> > Не в языке, в библиотеке
>
> Не в библиотеке, а как она написана, --- все библиотеки,
> написанные на Делфи очень не эффективно статически компилируются
> в смысле всё тех же бедных мегабайтов, например, тот же
> KOL - это библиотека статической компановки для Делфи, но
> она написана, как подтверждает сам автор с нарушением концепций
> языка Delphi Language, покрайней мере, концепций ООП VCL
> уж точно, поэтому мы и имеем то, что имеем - сверх малый
> размер.

Мы имеем не-ОО библиотеку с уменьшенными по сравнению с VCL возможностями. Этим малый размер и объясняется. AvL - библиотека ОО, но сильно урезанная по сравнению с VCL, чем объясняется экономия кода при ее использовании. Так что это именно из-за структуры библиотеки такой размер. Если хочешь посмотреть, что получается, когда неэффективно работает Smart Linking - попробуй сделать форму с кнопкой на Lazarus/LCL. Получается ехе метров на 6. В Delphi ехе файл сравнительно велик из-за большого количества кода, обеспечивающего удобства для программиста.

> Ну, за гнус точно не скажу, но студия(.NET) ест без проблем.

Да, знаю, проверял. Но строка int i, int j; не является объявлением переменной (ее появление просто в коде приводит к ошибке), а в описании цикла for допускается объявление без специальных оговорок.

to ors_archangel © (25.12.06 01:00) [180]:
>- совершенно не учитывается, что между override-методами одного класса
>всегда возможен inline
Это как? В одном из методов заменили вызов другого на его код? Угу. А потом в потомке еще раз перекрыли вызванный метод, и как это будет потом работать?

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

>- вообще ограничение без причины, как раз в циклах inline больше всего и
>нужен, странно, почему в forе ещё оставили
Читали по диагонали? Там чистым английским языком написано, что "in conditional expressions", то есть в условиях цикла, а не в самом цикле. Разница, надеюсь, понятна.

← →
Step by step (2006-12-27 05:00) [191]

> ors_archangel © (24.12.06 07:24) [165]
>
> Step by step! может ты подумал, что я хочу эксплуатировать
> твой ник? :)))) Я понял твоё мнение насчёт контроля ошибок,
> но вот слушай, писал ты i*2, i*2, шаг у тебя = 2, так?
> и вдруг забыл :( вот блин, а компилятор не поправит - это
> ведь логическая ошибка, а не синтаксическая, а вот если
> бы ты написал for i := 1 to 10 step 2 (извини за избитый
> пример), то такое было бы уже невозможно

Как же невозможно? Вдруг забыл, что степ 2, и пошло поехало.

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

> Step by step (27.12.06 05:00) [191]
> сложно

Ладно, не начинай, помойму не сложно, наверно - дело вкуса (в таких случая разработчики плюют на мнение программистов и делают как им нравится)? Хотя меня вставляет идея в цикле итерационного увеличения счётчика, например, задать шаг итерации…

А в [180] я такую чушь нёс несусветную, а заметил только vuk!

vuk! Большое СПАСИБО за исследование моего поста!

> vuk © (26.12.06 12:33) [190]
> >всегда возможен inline
> Это как? В одном из методов заменили
> вызов другого на его код?
> >- запрещено в inline-функциях юзать асм, можно было обойтись
> >ограничением на только поименнованный доступ к параметрам
> Дело не в параметрах, а в использовании регистров.

Да, я погарячился, в действительности есть только несколько случаев: если мы из override-метода вызывем не виртуальный метод, virtual-метод без overridов, либо override-метод без overridов (в потомках). Ты оч правильно заметил, я совсем неправ кругом :( А насчёт регистром мы ещё поговорим!

>> как раз в циклах inline больше всего и нужен
> Читали по диагонали?
> Там чистым английским языком написано, что "in conditional
> expressions", то есть в условиях цикла, а не в самом цикле.

Читал по горизонтали, справо налево :) Не будем забывать, что условия цикла выполняются каждую итерацию, если посмотреть на асм-код, то проверка условия осуществляется между label и "jmp", поэтому это реальный код, который выполняется в цикле (хотя и не в теле, да-да). И согласись, для этого ограничения действительно веской причины - прихоть какая-то: "не хотим - не будем".

В действительности, согласен с Mystic"ом, что inline не принципиален для программиста, мне просто странно, почему оптимизатор (ведь эти ограничения не для программиста, это ограничения компилятора) так его боится, ведь, хотя процессоры всё умнеют, но при этом стоимость call тоже не падает, раньше это стоило push eip + jmp и всё, а теперь это ещё сбрасывает декодеры, ухудшает выборку…

Так, кто тут ещё?

Vga © (25.12.06 21:46) [188]
> Если хочешь посмотреть, что получается, когда неэффективно
> работает Smart Linking - попробуй сделать форму с кнопкой
> на Lazarus/LCL. Получается ехе метров на 6. В Delphi ехе
> файл сравнительно велик из-за большого количества кода,
> обеспечивающего удобства для программиста.

насколько я знаю, где-то 5/6 - это debug info, а не код

← →
Step by step (2006-12-27 05:37) [193]

> (в таких случая разработчики плюют на мнение программистов
> и делают как им нравится)?

Наоборот. Опытные разработчики предерживаются стандарта стилевого оформления, обязательно дают понятные имена, а не func1 func2 func3, и придерживаются многих негласных соглашений. Всё это казалось бы сильно ограничивает, но зато сильно облегчает взаимопонимание.

Step by step, но ведь
i := 1; while i <= 257 do begin ля-ля-топаля inc(i,step); end;
- это такая искусственость: присвоение (это же цикл изменения счётчика, почему оно вынесено?), inc(i,step) (это можно забыть написать, само его положение сдесь как бы факультативное - вот сделали, а в while"е часто и нету такого), если же ты опять за свои умножения (я опять буду против), то это тоже накручивание подпорок, когда можно прямо выразись смысл - это минус всех ЯП - заставляют писать подпорки для мыслей.
Ещё значит: я захотел изменить шаг - у меня сущность шага в одном месте, у тебя - "Replace All", дальше, через конструкцию for i := a to b step s мы получаем контроль за read-only"ностью счётчика i (как и в обычном for, т.к. оператор отражает сущность!), а в while мы можем его изменить нечаяно, а ведь на ЯП должнобыть сложно писать неправильно, и просто - правильно. Ещё: ну не помешает нам потренеровать память, ты пишешь, что код нужен для чтения, аргумент - все будут путать for со step с for обычный или там, забывать, шаг, вот - пусть помучаются - лучше код поймут! Шаг - параметр цикла, его нельзя не учитывать ну не как, а то что по умолчанию он = 1 ещё в Бейсике отлично запоминается, там много умолчаний, и это здорово. Конечно, не научнообосновано, но ведь разные условия в if тебе лезут в память? А разные параметры функций, те же функции имеют параметры по умолчанию, которые то ж иногда приходится вспоминать (особенно, если чужок код), чувствую, я тебя не убедил, но ведь контроль ошибок реально возрастает при написании, заметь! И не надо думать, что я тут Бейсик пропагандирую, это (до .NET), вообще скорее скрипт...

← →
Step by step (2006-12-27 06:22) [195]

> ors_archangel © (27.12.06 05:58) [194]

Вместо while могу предложить использовать if и goto.

Однако язык существует в первую очередь для людей, а уж потом для компьютеров. "While" принято использовать когда счётчика нет. Поэтому когда написано "for", то читающему сразу ясно, что это счётчик.

> вот - пусть помучаются

Для этого есть сипиписка.

> ведь разные условия в if тебе лезут в память?

В if ничего не меняется.

> Step by step (27.12.06 06:22) [195]

> Вместо while могу предложить использовать if и goto.

Ты смелый человек!

> Однако язык существует в первую очередь для людей, а уж
> потом для компьютеров. "While" принято использовать когда
> счётчика нет. Поэтому когда написано "for", то читающему
> сразу ясно, что это счётчик.

Вот, я ж и предлаю, что когда я имею в виду "здесь цикл, где счётчик меняется от a до b с шагом s", я писал for i := a... ну ты знаешь :) for - именно он! Он означает счётчик -> ты прав && это for -> я прав, неужто консенсус?

> Для этого есть сипиписка.

Вот я и предлажил цикл с шагом! А ещё я предлагаю безусловный цикл, но правда не в этой ветке, ну и если ещё честней, то это всё ведь голословно, пока мы тут теорию уточняем, да практику вспоминаем, от меня, например, ни на 0.001% не зависит, что будет, напрмер, поддерживать компилятор dcc, так что пора закончивать разговор, я так думаю, а то грусно стало совсем :(

> В if ничего не меняется.

Если в if ничего не меняется -> в step ничего не меняется, так что не уходи от темы! Ты там компилятор не написал, случайно, какой-нить? Или у тебя чисто научные соображения для спора?

← →
Step by step (2006-12-27 06:45) [197]

> ors_archangel © (27.12.06 06:32) [196]
> от меня, например, ни на 0.001% не зависит, что будет, напрмер,
> поддерживать компилятор dcc,

И слава Богу!

> в step ничего не меняется,

[191]

> И слава Богу!
А мне жаль, только не говори, что не хотел бы чего-то поменять в Delphi Language!

> [191]
Рекурсия :)

ors_archangel, нужно в первую очередь менять своё мышление, оно более гибкое нежели язык. for ... in ... do появился, кто им пользуется? Генерируемый asm код видели? )

> - это такая искусственость: присвоение (это же цикл изменения
> счётчика, почему оно вынесено?), inc(i,step)

Все программирование -- искусственность. Кому-то не хватает конечных автоматов, и он предложит ввести конструкции вида
statemacine state Initial: I := 0; gostate ReadFirst; state ReadFirst: { ... } end;

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

Сишные циклы FOR в Паскаль не переводятся? Найти похожие ветки