OberonCore

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

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

Тов. Веселовский, как и иные товарищи, конструктивно выступил здесь: http://oberspace.dyndns.org/index.php?topic=4.0

Кстати, а как это при компиляции переполнение считать? Это же возможно только для константных выражений.

Что-то не видать ни одной альтернативы. Ни в сравнении с другими вариантами, ни даже просто с разбором по пунктам.

Итого, "конструктивность" типа: Сергей Прохоренко, мы Вам советуем КП в качестве первого приближения не рассматривать, а (самому) поискать что-нибудь получше.

Мы говорим о разных вещах. Длинных типов обычно даже слишком много разных, что ведет к несовместимости по типу. Поэтому, например, Вирт все их просто отбросил в Обероне-07. Ему это было сделать просто - он ведь не разрабатывает игры - ему и не нужны длинные типы.

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

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

Я прошу внимательнее прочитать о проблемах, сформулированных разработчиком игр. Разумеется, ему известно и о длинных библиотечных типах, и об обработке прерываний при целочисленном переполнении и т.п. Это всё не является реальным решением проблем, это лишь попытка хоть как-то уменьшить ущерб. Ведь по его статистике на перечисленные им проблемы приходится 50% багов!

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

Здесь я попытаюсь перечислить средства предупреждения типичных ошибок в программах:
1. Сборка мусора и Умный указатель
2. Многомерные динамические массивы и Цикл foreach
3. Целые числа произвольной длины
4. Строки произвольной длины
5. Компилятор должен выявлять использование переменных, которые "выше по тексту" не получают значение. Это не абсолютная гарантия от ошибки, так как, например, переменная может якобы "получать" значение в неиспользуемой ветви условного оператора.

Мы где-то уже обсуждали эту тему - foreach из-за своей "отначаладоконцовости" оказывается узкоприменимым (если нормально составлять алгоритмы).

С другой стороны, его удобство проявляется не на обычных (встроенных) массивах-последовательностях, а на разных объектах.
Так в чём проблема? - давно известен другие варианты: Carrier-Rider, итераторы - суть одна: получаем объект доступа (каретку) и ей "бежим".
Rider-ы прекрасно используются в любой сложности цикле, т.к. используются они вместе с WHILE:

WHILE (райдер не достиг конца) & что-угодно-ещё DO
....
райдер.дальше
END

(И в С++ нет никаких foreach и даже for. Тамошний for - это while, с явной записью условия и шага.)

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

+

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

foreach'и бывают разными. Может быть, Вы имели дело с неудачными, и надо сделать (или позаимствовать) другой вариант? Например, с не столь безальтернативной "отначаладоконцовостью"?



Чем райдер лучше, чем foreach? Может быть, между ними нет столь жесткой границы, и возможно что-нибудь гибридное? Райдеры и итераторы чем-нибудь отличаются? Можно ли их применять в языке, в котором нет классов, вроде Оберон-07?



Ну, С++ для меня не авторитет. Я бы охарактеризовал этот язык как "головную боль".

Что касается невозможности забыть, то я с Вами согласен. Но "можно применять" - не то же, что "лучше применять".

Так это будет WHILE и райдер, как раз.

foreach - это райдер-итератор, спаянный намертво с циклом, при этом с циклом, который идёт от начала до конца.
Максимально специализированная вещь. Если, конечно, не разрешать "стоп-кран" break и "прыжки из поезда на ходу".

Столько раз забывал про INC(i) и другие условия продолжения в конце цикла, что весьма ценю for-аналоги. Это же касается и начального значения переменной цикла. В ходе работы i:=0 либо случайно удаляется, либо не прописывается. И пошёл цикл со случайного шага.

Меня пока не убедили аргументы в пользу разделения foreach на while и итератор. Зачем нужен итератор для обращения к элементам массива вне цикла? Не нужен. А в цикле их лучше совместить - меньше ошибок будет, да и нагляднее. А дополнительное условие продолжения цикла можно вставить и в foreach - тогда никакие операторы досрочного выхода из цикла не понадобятся. Вот для всяких там списков, стеков, очередей и прочих контейнеров пусть будут встроенные итераторы - там они смотрятся "к месту". Хотя, может быть, и для них можно будет foreach приспособить. Главное, что программист будет абсолютно уверен в невозможности выхода индекса за границы массива. А контроль в рантайме - это паллиативное (слабое) решение проблемы.

Александр Ильин, кажется, как-то говорил, что отказался от FOR для единообразности. я тоже решил попробовать:
- уже давно FOR не использую
- и проблемы с "забывал про INC(i)" были только на первоначальном этапе
- теперь их нет
Итого: это вопрос привычки.

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

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

я говорю о своём опыте работы на КП. А Вы, Сергей, делая заключение, каким опытом руководствуетесь? Вы говорили, что программ не пишите, но, наверное, читаете? По-моему, для Вашей работы по анализу и отбору, надо читать в больших объёмах и из разных источников (хотелось бы, что Вы подробнее рассказали)...

Подтверждаю. До сих пор не использую for.

Проблем с забытым INC не бывает (ну, может быть раза три за последние три года). Для вставки шаблонных блоков кода использую плагин WebEdit (аналог F5 в Школьном ББ), просто добавил в шаблон WHILE строку "INC(i)". При необходимости заменяю на "obj := obj.next" или что там ещё требуется по контексту.

С другой стороны, я понимаю, что for (без break!) добавляет немного читабельности и сокращает запись алгоритма на пару строк.

И я не использую. Даже не помню, есть он в языке или нет

Для приобретения опыта нужно именно писать, а не читать (IMHO), либо читать и быть "семь пядей во лбу" (что тоже не исключается).

Интересно, что я тоже for использую только в самых простых случаях. Когда надо заполнить массив-контейнер начальными значениями...
99,9... моих циклов - это while...