Здравствуйте, Sergey J. A., Вы писали:

SJA>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Одно дело ....

СГ>>а другое дело ...

SJA>Так значит, мало того, что правило "один вход-один выход" работает не для всех циклов, но ещё и не всегда для остальных ?
SJA>Вам ещё не кажется, что Оберон это просто какой-то уродец ?

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

Здравствуйте, jazzer, Вы писали:
J>Правильно, но они же не знают про прагмы
Вот как раз знают. Ни разу не встречал такого, чтобы кто-то искал такие прагмы грепом, но в случае необоснованного применения можно нарваться очень и очень тяжело. Потому как намеренная попытка обмануть руководство гораздо хуже, чем банальная некомпетентность.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>К компиляторам-то это как относится?
Очень просто. Сергей, компилятор языка должен быть максимально интеллектуален в рамках своих обязанностей. Он для того и пишется, чтобы выбирать максимально эффективную реализацию высокоуровневых мыслей программиста. Если язык накладывает на компилятор ограничения, то виноват язык, а не компилятор. Иначе бы мы до сих пор программировали на макроассемблере.

СГ>Откуда компилятору знать какая ветвь в IF наиболее вероятна главная или побочная?
Ну, во-первых, он может это все-таки знать. Как минимум путем статического анализа.
СГ>Он компилирует так как написано.
Сергей, компиляторы, компилирующие "как написано", перестали применять в коммерческом программировании лет наверное пятнадцать назад.
СГ>Откуда процессору знать какая ветвь более вероятна? Ни откуда ему это знать нельзя. А раз ни откуда это заранее узнать нельзя, то логично всегда начинать заранее подгружать данные из главной ветви.
Сергей, вы бы почитали что-нибудь из того, что вам советуют. Для справки: соврменные процессоры предсказывают вероятность переходов уже поколений пять, если не шесть. И очень хорошо предсказывают. Лучше, чем программист. Вот, к примеру, как вы думаете, сколько раз будет сбрасываться конвеер в таком примере:

for(int i=0; i<N; i++)
  if (i & 1)
      cout << "odd";
    else
      cout << "even";

? Тут исполнение идет каждый раз по другой ветке. Правильный ответ: будет не более двух сбросов. Далее процессор запомнит паттерн чередования и будет следовать ему. Более того, процессор будет считать условие проверки "остаемся в цикле" верным, и ошибется только один раз — когда i таки достигнет N.
В общем, у вас катастрофически не хватает знаний об устройстве современных процессоров и компиляторов. Причем самое для вас опасное — это то, что вы основываете на этом невежестве далеко идущие выводы о том, как должен вести себя программист по отношению к компилятору и т.д. С этой точки зрения попытки рассуждать о преимуществе одних языков над другими выглядят несколько нелепо. Вы изначально строите неверную модель ситуации. Вряд ли язык, идеально подходящий вашему воображаемому программисту, будет подходить программисту реальному. Именно потому, что реальный программист живет в другом окружении.

СГ> А раз так, то и программист должен главную ветвь делать наиболее вероятной.
Как обычно — из неверного предположения делается неверный вывод.
СГ>В Дельфи это между прочим официально рекомендуют на полном серьезе (Тейксейра, Пачеко). А откуда компилятору-то знать?
Кошмар какой. Ну как откуда? Сергей, я понимаю, что в академической среде принято пренебрегать современным состоянием техники. Но настолько-то это делать нельзя! Практически любой современный компилятор С/С++ в состоянии выполнить такой анализ. У компилятора Delphi выполнить оптимизацию несложной программы действительно получается не лучше, чем у паралитика провести операцию на мозге гаечным ключом. Но это далеко не лучшее достижение компиляторщицкой мысли.

Здравствуйте, Mamut, Вы писали:

M>И все же, свою точку зрения я подтвердил фактами. Ваш ход

Я написал:

В Си-образных языках, циклы while/do не удовлетворяют этим определениям так как могут быть завершены еще и по break и goto.

это так. Ну такие определения я написал. А Вы в ответ: "Не соглашусь." Как можно не согласится с тем что они не удовлетворяют указанным мной определениям?

А на счет тех определений, вот еще информация:

Рассмотрим код:

REPEAT узнавать где брод UNTIL узнал
Лезть в воду

То что цикл REPEAT не завершится никаким другим способом, кроме как тогда когда "узнал" станет истиной гарантирует то, что можно переправится через реку.


Следующий код:

WHILE отмерено меньше семи раз DO отмерять END
Отрезать

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

Если бы не было таких гарантий, то нельзя было бы так программировать

Здравствуйте, jazzer, Вы писали:

J>Скажи честно, тебе самому не надоело еще фигней заниматься?
Не волнуйся. Сергей готов на все, лишь бы доказать преимущества Оберона. Правда, он не в курсе,
— что компиляторы С умеют выдавать warning на практически все ошибочные ситуации, которые можно только придумать.
— что на языке С не нужно переупорядочивать программу для того, чтобы компилятор смог сгенерировать оптимальный код
Но это не имеет никакого значения. Все эти факты рассматриваются через призму утверждения "Оберон рулит", и неудачные для оберона — попадают в невидимую часть спектра...

Вообще наблюдается весьма забавная тенденция. Сергей со своим обероном — не единственный поклонник академических проектов. Есть и другие Что меня забавляет — так это искреннее стремление перенести академические проекты из тепличной почвы мини-задач в современный мейнстрим. И происходит это, имхо, от катастрофического недостатка опыта по написанию настоящих приложений.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Mamut, Вы писали:

M>>И все же, свою точку зрения я подтвердил фактами. Ваш ход

СГ>Я написал:
СГ>

СГ>В Си-образных языках, циклы while/do не удовлетворяют этим определениям так как могут быть завершены еще и по break и goto.

СГ>это так. Ну такие определения я написал. А Вы в ответ: "Не соглашусь." Как можно не согласится с тем что они не удовлетворяют указанным мной определениям?

Просто в оригинальном сообщении было дано:

По определению цикл REPEAT может завершиться...
По определению цикл WHILE может завершиться...

Так как вы не сказали, что это ваши определения, то поэтому и не согласился.

СГ>А на счет тех определений, вот еще информация:

[skip]

СГ>То что цикл WHILE не завершится никаким другим способом, кроме как тогда когда будет отмерено не меньше семи раз, гарантирует то, что отрезано будет правильно.

СГ>Если бы не было таких гарантий, то нельзя было бы так программировать

Ну дык. Никто не мешает и в С/С++ так же написать. Дело в том, что С не мешает писать "идеально-структурный" код (по Дейкстре), но и не мешает писать и код по "обновленной концепции структурного кода" (пункт третий здесь). И еще многим другим парадигмам программирования он тоже не мешает.

"структурный Дейкстры"

int measurement_count = 0;
while(i != 7)
{
  i++;
  measure();
}

После выхода из цикла i будет гарантированно 7. И цикл гарантированно прокрутится 7 раз. Просто дело в том, что надо уметь работать с тем инструментом, что есть на руках.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, faulx, Вы писали:

F>>Посмотрел в интернете, кажется, Паскаль действительно не запрещает. Позор! Интересно, как с этим в Аде и Обероне?

СГ>В Дельфи (начиная с какой-то версии) запрещает (компилятор ругается — переменная цикла всегда размещается в регистре процессора и, вообще говоря даже не обязана сохранятся потом в память (после завершения цикла ее значение НЕ ОПРЕДЕЛЕНО), об этом даже много спорили на форумах когда выяснялось, что дельфийский for работает значительно быстрее чем сишный for для целых чисел (ведь сишный for обязан сохранять значение переменной-счетчика из регистра обратно в оперативную память на каждой итерации, а это долго), лично однажды проверял), а в Обероне 2 FOR — это сахар над WHILE — запрещать нечего. В Ада — понятия не имею.
Сергей, ваши представления о компиляторах просто чудовищны.
Во-первых, Delphi не обязан размещать переменную цикла в регистре. Это очевидный бред. Иначе бы при количество вложенных циклов было ограничено количеством регистров процессора. Даже такой тупой компилятор позволяет некоторую гибкость в назначении регистров.
Во-вторых, сишный фор никому ничего не обязан. Компилятор не только умеет размещать переменную в регистре; он также умеет разворачивать циклы, выносить константы за цикл, выделять общие подвыражения и еще очень много чего. Более того, большинство синтетических примеров, которые вам удастся придумать, вообще выкинут цикл напрочь. Например вот такой код:

int n=0;
for(int i=0; i<5;i++)
n +=i;
// дальше некоторое использование n

Современный компилятор приведет этот код к такому же бинарнику, как и

int n = 10;

СГ>Вы правы. По этому поводу Никлаус Вирт как раз и ругал все эти дебагеры. А имеено, он говорил, что существуют программы, которые нельзя дебажить — сборщик мусора, например. В его статье про создание Оберона он на этом специально акцентирует внимание. Сборщик мусора должен быть написан с особой тщательностью.

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

"Что такое процесс отлаживания программы? Это процесс избавления программы от лажи." (с)

MN>>Ну продемонстрировали вы числа... И что? Я тоже много чисел знаю...

СГ>Так продемонстрируйте! Создайте новую ветку в форуме. Покажите числа. Кто знает, может быть народ тоже накинется их обсуждать. А может проигнорирует. Мои числа почему-то не проигноровали, хотя могли бы. Наверное мои числа получились числятее чем обычные.

Были и числа. Только народ на них реагировал не опровержениями, а положительными высокими оценками. И оценки на числах, опровергающивх Ваши, куда выше, нежели у Ваших первоначальный чисел.

Сравните хотя бы это

Автор: Сергей Губанов
Дата: 22.06.05

и здесь

Автор: Сергей Губанов
Дата: 09.06.05

Здравствуйте, Сергей Губанов, Вы писали:

СГ>

СГ>Оператор
СГ>

СГ>   FOR v := beg TO end BY step DO statements END
СГ>

СГ>эквивалентен следующему
СГ>

СГ>   temp := end; v := beg;
СГ>   IF step > 0 THEN
СГ>      WHILE v <= temp DO statements; v := v + step END
СГ>   ELSE
СГ>      WHILE v >= temp DO statements; v := v + step END
СГ>   END
СГ>

И ты хочешь сказать, что компилятор, в случае если step переменный, рожает две копии statements ? Маньячно.

Кстати говоря, при step=0 в "эквивалентном коде" мы наблюдаем 6-секундную задержку
Это заодно к вопросу о верификации программ, и облегчает ли её Оберон.

Скорее, FOR эквивалентен вот такой конструкции

v_ := beg; end_ := end; step_ := step; (* параметры цикла поменять в ходе работы нельзя *)
WHILE (step_>0 AND v_<=end_) OR (step_<0 AND v_>=end_) DO (* при step_=0 условие ложное *)
  v := v_; (* то же относится и к переменной цикла *)
  statements go here;
  v_ := v_ + step_;
END;

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Мы можем выйти из нескольких вложенных WHILE/REPEAT циклов. Внешний цикл делаем LOOP-ным, а все вложенные циклы делаем WHILE/REPEAT-ными. Тогда EXIT прервет все циклы сразу. А вот если бы EXIT прерывал бы не только LOOP-ные циклы, но и все остальные, то из нескольких вложенных циклов (без goto или RETURN) выйти было бы (по быстрому) нельзя.
СГ>

СГ>LOOP
СГ>  ...
СГ>  WHILE...
СГ>    ...
СГ>    REPEAT... (* много вложенных WHILE/REPEAT циклов *)
СГ>      ...
СГ>      WHILE...
СГ>        ...
СГ>        IF c THEN EXIT END; (* выход из всех циклов, на конец текущей LOOP-ной итерации *)
СГ>        ...          |
СГ>      END;           |
СГ>      ...            |
СГ>    UNTIL...;        |
СГ>    ...              |
СГ>  END;               |
СГ>  ...                |
СГ>END                  |
СГ>...---<--------------+
СГ>

СГ>Конечно, если вложенные циклы, тоже LOOP-ные, то описанный тут механизм работать не будет (EXIT выведет только на конец ближайшего LOOP-а).

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, CrystaX, Вы писали:

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

СГ>Не английский, а США-совский. И это очень существенное уточнение. Это потому, что мог бы быть русский, если бы произошла мировая революция; или немецкий если бы планы фашистов сбылись; или китайский если бы китайцы завоевалю всю евразию. Или японский, если бы у них у первых появилась ядерная бомба. А так как в холодной войне победили именно США, то и язык по всему миру ихний. Кроме того они и компы с программами для них первее всех расплодили. Аналогично у Java нет преимуществ перед Оберонами кроме как то, что за плечами Java стоит Sun. Аналогично про .NET с Microsoft.

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Вы правы. По этому поводу Никлаус Вирт как раз и ругал все эти дебагеры. А имеено, он говорил, что существуют программы, которые нельзя дебажить — сборщик мусора, например. В его статье про создание Оберона он на этом специально акцентирует внимание. Сборщик мусора должен быть написан с особой тщательностью.
Нормально сборщики мусора отлаживаются — вполне обычного отладчика Visual Studio мне было вполне достаточно, когда я искал багу в Boehm GC и когда писал свой GC.

Делаем вывод: Н.Вирт еще и отладчиками пользоваться не умел.

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

При определенных условиях он может вообще выкинуть переменную цикла. У меня однажды был примерно такой цикл:

const int indx[] = { 1, 2, 4, 5, 10 };
for(int i = 0; i < sizeof(indx)/sizeof(indx[i]); ++i)
    {
    process(indx[i]);
    // какая-то обработка...
    }

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

Здравствуйте, Кодт, Вы писали:

К>Только не говори, что THEN короче, чем {}

пожалста — замените на односимвольный терм и будет короче, а вообще на сишных фэнов в этом форуме смотреть становиться всё неинтереснее и не интереснее, чем на данную ветку в которой они кусаются и вообще от синтаксических программистов меня уже тошнит аттавизм, мда {}ХЪ

Здравствуйте, qwertyuiop, Вы писали:
Q>Вместо переменной цикла он создал указатель на этот массив и завершал цикл когда он указывал на 10. Очевидно, такое возможно если массив константный (кстати, о пользе константных массивов) и если последнее значение больше нигде в массиве не встречается.
Очевидно, что для неконстантного массива можно заранее вычислить адрес конца и сравнивать указатель именно с ним. Скорее всего, так и было дело в вашем случае (потому, что сравнение адреса с константой быстрее, чем сравнение значения по адресу с константой).

Здравствуйте, mister-AK, Вы писали:

К>>Только не говори, что THEN короче, чем {}

MA>пожалста — замените на односимвольный терм и будет короче,

На здоровье: cond() ? ontrue() : onfalse()

MA>а вообще на сишных фэнов в этом форуме смотреть становиться всё неинтереснее и не интереснее, чем на данную ветку в которой они кусаются и вообще от синтаксических программистов меня уже тошнит аттавизм, мда {}ХЪ

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

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, moudrick, Вы писали:

M>>С++, кстати, тоже начинался с академической разработки. А практики его потом подхватили.
M>>Ссылку навскидку не нашел, извините.

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

J>Почитай D&E.
Моя настольная книга.
AT&T (где начинал разрабатываться C++), да будет Вам известно — исследовательская лаборатория, стало быть там академическая среда, не так ли?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, jazzer, Вы писали:

J>>Потому что он создавался именно для облегчения программирования на С (как и С по отношению к асму, кстати).
J>>Цель сугубо практическая.
J>>И обкатывался язык не на теоремах, а в руках действующих программистов на С.
J>>Почитай D&E.

СГ>Не надо быть прорицателем, чтобы понять, что реальная цель у аспиранта Страуструпа была защитить диссеру чтобы его взяли на работу.

По себе судите?
Если бы в результате моей диссеры появилось нечно подобное C++, я бы считал наполовину выполненным дело совей жизни

Здравствуйте, mister-AK, Вы писали:

MA>пожалста — замените на односимвольный терм и будет короче, а вообще на сишных фэнов в этом форуме смотреть становиться всё неинтереснее и не интереснее, чем на данную ветку в которой они кусаются и вообще от синтаксических программистов меня уже тошнит аттавизм, мда {}ХЪ

"Мы прочитали ваш пост и приняли решение приобрести такую же траву"