OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 22 Ноябрь, 2019 15:47

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 145 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 18 Февраль, 2010 07:02 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
AVC писал(а):
Info21 писал(а):
Ну, можно же забыть RETURN. (Или это не по части структурности?)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 08:22 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3109
Откуда: Астрахань
Info21 писал(а):
AVC писал(а):
Info21 писал(а):
Ну, можно же забыть RETURN. (Или это не по части структурности?)

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

Проблемы неинициализированных переменных в НОРМАЛЬНОЙ среде быть просто не должно! Отсутствие инициализации переменной должно караться "расстрелом" и квалифицироваться как ГРУБАЯ ошибка. Меня удивляет, почему этого до сих пор не сделали? Это даже не компилятор, это редактор должен следить, БЛИН!!!!!!!!

Последующее обсуждение выделено: viewtopic.php?f=27&t=2372


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 09:18 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Info21 писал(а):
Но проблема инициализированных переменных есть всегда и так. Зачем к ней добавлять еще одну проблему.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 09:35 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Info21 писал(а):
В целом я за жесткость и отсутствие мелочной вариативности на низком уровне -- но с конкретной целью: чтобы не отвлекаться от структуры программы.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 09:40 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4526
Откуда: Россия, Орёл
AVC писал(а):
Но я все же хочу отметить, что некоторые "трюки" вызваны объективной необходимостью (как правило, ограниченностью ресурсов)
Может стоит называть это обоснованной оптимизацией? А трюками - необоснованную/преждевременную?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 09:52 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Евгений Темиргалеев писал(а):
AVC писал(а):
Но я все же хочу отметить, что некоторые "трюки" вызваны объективной необходимостью (как правило, ограниченностью ресурсов)
Может стоит называть это обоснованной оптимизацией? А трюками - необоснованную/преждевременную?

С необходимостью различать обоснованную и необоснованную оптимизацию полностью согласен.
Но и тогда, когда оптимизация обоснована, все равно порой приходится прибегать именно к трюкам -- неочевидным (иногда даже остороумным) приемам, весьма далеким от стандартных оптимизаций компилятора.
(Т.е. для меня слово "трюк" не обязательно связано с негативной оценкой. Но можно попробовать придумать/вспомнить какое-нибудь другое слово: например, "хак", как Валерий Лаптев оценил организацию линейного поиска в двумерном массиве. :) )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 09:57 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Из книжки "Построение компиляторов", стр 184. По моему выглядит очень симпатично.
Код:
PROCEDURE negated (cond: LONGINT): LONGINT
BEGIN
  IF ODD(cond) THEN RETURN cond - 1 ELSE RETURN cond + 1
END negated;

PROCEDURE merged(L), L1: LONGINT): LONGINT
VAR L2, L3: LONGINT;
BEGIN
  IF L0 # 0 THEN
      L2:= L0;
      LOOP
          L3:= code{L2} MOD 40000H;
          IF L3 = 0 THEN EXIT END;
          L2 := L3;
      END;
      code[L2]:=  code[L2] - L3 + L1; RETURN L0
  ELSE RETURN L1
  END;
END merged;


Последний раз редактировалось Axcel Четверг, 18 Февраль, 2010 13:46, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 10:21 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4526
Откуда: Россия, Орёл
AVC писал(а):
Но и тогда, когда оптимизация обоснована, все равно порой приходится прибегать именно к трюкам -- неочевидным (иногда даже остороумным) приемам, весьма далеким от стандартных оптимизаций компилятора.
"неочевидные (остороумные) приемы" и любые другие действия с целью минимизировать потребляемые программой ресурсы разве не есть оптимизация?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 10:25 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Axcel писал(а):
По моему выглядит очень симпатично.

:mrgreen:
Насколько я понимаю, так в учебном компиляторе для Оберона-0 "патчится" код для сложных булевских выражений.
Виртовские компиляторы генерят сразу машинный код (скорость компиляции). Уверен, если бы генерировался ассемблерный код, все выглядело бы не так страшно. :roll:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 10:31 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Евгений Темиргалеев писал(а):
AVC писал(а):
Но и тогда, когда оптимизация обоснована, все равно порой приходится прибегать именно к трюкам -- неочевидным (иногда даже остороумным) приемам, весьма далеким от стандартных оптимизаций компилятора.
"неочевидные (остороумные) приемы" и любые другие действия с целью минимизировать потребляемые программой ресурсы разве не есть оптимизация?

Конечно, можно назвать это "оптимизацией".
Но у меня слово "оптимизация" вызывает две ассоциации: (1) исследование операций и (2) улучшение, "вылизывание" компилятором/программистом уже готового кода.
"Трюк"/"хак" же заранее учитывает ограниченность ресурсов, это кардинально отражается на структуре решения (оно просто "другое").


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 10:34 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Извините, а что тут страшного? Я имею ввиду конкретный код. Сам компиляторов не писал. :(


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 10:44 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Axcel писал(а):
Извините, а что тут страшного? Я имею ввиду конкретный код. Сам компиляторов не писал. :(

Ну, даже не знаю. :roll:
Здесь весь джентльменский набор: и множественные RETURN, и EXIT, и хранение списка непосредственно в генерируемом машинном коде (кстати, "трюк").
Такое впечатление, что Федор Васильевич срочно должен сделать Николаю Вальтеровичу небольшое а-та-та. :oops:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 11:27 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
AVC писал(а):
срочно должен сделать Николаю Вальтеровичу небольшое а-та-та. :oops:
Что мог, я уже сделал.
(И он все разумные а-та-та разумно принял.)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 11:33 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
AVC писал(а):
Info21 писал(а):
Но проблема инициализированных переменных есть всегда и так. Зачем к ней добавлять еще одну проблему.

По сути, это одна и та же проблема ...
По сути, но не по форме.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 13:20 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9160
Откуда: Россия, Орёл
Info21 писал(а):
Стоит их поучить, как от всех таких штук начинает колбасить при мысли о том, что и это им надо будет еще втолковывать.


Это точно... Времени дико мало, немыслимо мало. Т.к. в школе - ничего; начинаешь с "таблицы умножения" в алгоритмизации.

Сейчас вот бьюсь над дидактической задачей, как лучше всего научить понимать вообще устройство памяти и структур данных в ней. Нужен исполнитель. Визуальный. Иначе НЕ ВИДЯТ они, как там всё это связывается. Как с указателями работать. То же ООП понять до конца можно, только "руками" почувствовав эти идеи сначала (как оно технически там). Времени ждать, пока дойдёт "инсайтом" в процессе, нет - и неэффективно это; методика нужна.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 24 Март, 2010 21:34 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Евгений Темиргалеев писал(а):
Berserker писал(а):
Лучше больше времени потратить на создание кода, чем отладку или доработку в будущем. Вполне возможно, что если взять за правило структурный стиль , то через какое-то время это войдёт в привычку.
Попробуйте. Если взять соответствующий язык, который не даст расслабляться, то 100% через некоторое время Вы обнаружите, что так и есть.

Переписал весь код текущего проекта ("Система оценки конкурсных предложений", ~3.5тыс. строк) в структурном стиле. Появилась тотальная неприязнь к break/continue/exit (аналог return в ББ).
Как мыслилось раньше:
....ветвения, цикл
....условие выхода - освобождение памяти, очистка мусора
....
....другое условие выхода - освобождение памяти, очистка мусора
Возникали мысли вместо break-ов использовать GOTO на блок с уборкой мусора. Сейчас этого нет. Я знаю на 100%, что код достигнет конца процедуры, и могу расположить там любые действия по финализации работы.
Также стала абсолютно дикой концепция использования исключений для обработки ошибок (в Делфи это сплошь и рядом). Подобные неявные goto рушат основу структурного стиля, заставляя шарахаться от каждого вызова метода или функции. Считаю необходимым применение исключений только там, где это действительно нужно - в математических операциях (TRY a+b EXCEPT MathError END).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Май, 2012 13:37 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков писал(а):
Сейчас вот бьюсь над дидактической задачей, как лучше всего научить понимать вообще устройство памяти и структур данных в ней. Нужен исполнитель. Визуальный. Иначе НЕ ВИДЯТ они, как там всё это связывается. Как с указателями работать. То же ООП понять до конца можно, только "руками" почувствовав эти идеи сначала (как оно технически там). Времени ждать, пока дойдёт "инсайтом" в процессе, нет - и неэффективно это; методика нужна.
Была идея - использовать схемы типов. Имея в виду, что были уже среды частично визуального исполнения - тот же ПЕКАН: viewtopic.php?p=68848#p68848. Но там как раз до схем связывания типов не дошли...

Имеется в виду язык с алфавитом как в этом определении. И схемами такого вида, как здесь. Но не всё так очевидно, как в в приведённом примере, ясное дело. Поэтому суть в том, что указатели представлены как разъёмы на концах связей, "прошивающих" дерево типов. А реальные "сшивки" показываются для конкретных состояний исполнения. В принципе правильно связывать с положением на "варианте использования" (ну, ветке "древесной развёртки" кода, как здесь).
Т.е., выполнили эту вершину на импер-схеме - схема типов стала такой-то. Выполнили следующую (ну или там через несколько малосущественных перескочили) - уже другой.
Разумеется, к этому можно добавить и "устройство памяти" поячеечное. Как в том же ПЕКАНЕ - или у Рембольда - в Гл. 8, когда он размещение в памяти объясняет. Но и тут, мне кажется, надо наложить именно схемные представления на метафору "ленты памяти". Проще говоря - показать как "укладку" схем на ленте. Считая ячейку местом для одной вершины (для простоты).

О реализации сего дела. Ясно, что полноценная - это некий редактор. :) Но для дидактики можно просто разобрать по такому принципу одну-две задачи. И составить методу. И даже запрограммировать - но в режиме визуализатора ("перелистывателя страниц", то бишь :))... "Гетерогенная очередь" Свердлова подошла бы. Кстати, думал сам отрисовать - но работа немаленькая... без удобного редактора... ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 23 Май, 2012 19:10 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вероятно, наиболее очевидный ответ на это "почему" - потому, что тем самым вполне реализуется сказанное здесь (курсив мой):
...
Однако речь именно об алгоритмике – о программировании, очищенном от всего случайного.
...
Здесь прежде всего мы видим, что алгоритмика понимается не как определение одного лишь потока управления процесса, описываемого программно строго, т.е. для исполнителя-"машины". Но как определение процесса решения в целом.
Можно навести мосты и с другими мыслями разных авторов... возможно, когда-нибудь удастся...

Ну, вот первый мостик... с Лавровым (вторая выдержка здесь: viewtopic.php?p=71221#p71221).
Из формулировки алгоритмической разрешимости (на с. 144), в частности, следует, что в бщем случае необходим прогон программы для установления её соответствия тем или иным требованиям.
    "Итак, отладка в принципе не м.б. исключена?" - радостно воскликнут сторонники "наивного" информоделирования? Тогда и структурность вроде ни к чему?.. А вот тут и вступает в действие сказанное Фёдором Васильевичем... Ибо чем менее мы "очищаем от случайного" язык и описания на нём - тем менее мы м.б. уверены в причинах отклонений от требований. И тем больше нам придётся отлаживать...
Тогда как если мы с самого начала структурировали описание на основе логичности - то и отклонения, как правило, можем выявить путём логического анализа исполнения. Вот как здесь: viewtopic.php?p=72732#p72732 - условие цикла не отвечало требованиям - но товарищ посмотрел и уточнил (возможно, даже и без отладок :wink:). И тем более - изменить работу под новые требования. Пример чему... ну хотя бы здесь, наверное: viewtopic.php?p=72758#p72758 (тоже в рабочем порядке - выявили проблему - локализовали - исправили)...


Последний раз редактировалось Владислав Жаринов Суббота, 26 Май, 2012 21:17, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 26 Май, 2012 10:21 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Да, ещё о дидактике исполнения...
В отсутствие учебного редактора, охватывающего сей предмет, можно пользоваться предложениями Лаврова из работы, представленной здесь: viewtopic.php?p=71221#p71221. В пп. 2.3.4 и 2.5.1 он её использует для представления ссылочных структур.

Кстати, вторая часть книги вообще любопытна по изложению алгоритмики. В частности, показывается, как некоторые случайности мешают... :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Июль, 2012 10:30 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот ещё дискуссия: http://www.rsdn.ru/forum/philosophy/4797675.flat.1.aspx.
То, что там ближе к концу возникает о нетекстовых формах записи - в переводе должно означать, что ключевые слова выбора заменяются либо структурными скобками по Прохоренко, либо графикой вершин и линий. А всё, что по семантике и прагматике конструкции выбора - возможно, представляет интерес.. хотя бы для иллюстрации инженерности/неинженерности подходов участников... :)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 145 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB