OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 17:39

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




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 19 Сентябрь, 2020 21:53 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Коллеги,

под постом в сообществе Гершель https://vk.com/herschelcompiler?w=wall-196590190_62_r75
Илья Ермаков писал(а):
научить бы компилятор определять обращение до инициализации


Как я это понимаю: было бы полезно (в ряде случаев?) иметь гарантии того, что использование неопределенных значений переменных приводит к аварийному останову. Это можно было бы ввести в компилятор как опцию, наподобие проверки области допустимых значений (range checks, разд. 12 Platform-specific issues). Включаешь, обращаешься к переменной с неопределенным значением - и получаешь авост.

Напомню, что ныне Сообщение о языке гарантирует инициализацию только указательных и процедурных локальных переменных до выполнения тела процедуры. Это позволяет компилятору КП не инициализировать локальные переменные других типов, и СР2 так и делает.

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

Что думаете по поводу целесообразности и технической возможности таких проверок?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Сентябрь, 2020 23:29 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Нет, рантайм-проверка дорога, смысла не имеет.
Я имел в виду статическое выявление.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Сентябрь, 2020 01:09 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Статическое - это тогда не компиляторная, наэн, задача.

А инструмент Анализатор - он ведь показывает случаи use before set?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Сентябрь, 2020 16:31 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Статическое выявление использования неинициализированной переменной полезно везде, где легко достижимо, но в общем случае является алгоритмически неразрешимой задачей.

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

Опыты через промежуточное представление на C показали, что при совмещении простого статического анализа, посильное и компилятору, с динамическим на проверку неинициализированности дополнительно уходит ~ 10 % при не оптимизирующей сборке и ~ 25% при сильно оптимизирующей. Оптимизированная версия с проверками в ~3 раза быстрей неоптимизированной без проверок.

Пример, как это может быть сделано для статической и динамической проверок


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 20 Сентябрь, 2020 23:35 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Comdiv писал(а):
Пример, как это может быть сделано для статической и динамической проверок


Интересная "песочница"!

А что же там "под капотом"? как посмотреть?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Сентябрь, 2020 00:47 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Всё давно открыто


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Сентябрь, 2020 09:14 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Вот надо бы по каждой фиче языка собрать подобную премудрость.

Может, просто завести раздел с названием "Почему в Обероне сделано так?" -- одна тема -- одна фича.
Фича -- объяснение эксперта -- утрясание деталей и непоняток.

Начать с неиниц. переменных и ответа Comdiv'а.

Какие-то ветки будут трактовать общие принципы, на которые опирается сразу несколько решений.

Был бы крайне полезный ресурс для начинающих (с коими я постоянно имею дело).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Сентябрь, 2020 15:21 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Info21 писал(а):
Может, просто завести раздел с названием "Почему в Обероне сделано так?" -- одна тема -- одна фича.
Фича -- объяснение эксперта -- утрясание деталей и непоняток.

Пожалуйста: viewforum.php?f=158


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 22 Сентябрь, 2020 22:37 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Info21 писал(а):
Может, просто завести раздел с названием "Почему в Обероне сделано так?" -- одна тема -- одна фича.
Если отвечать строго на поставленный вопрос, то во многих случаях правильным ответом будет потому, что так проще. То, что иногда это будет совпадать с решением для улучшения надёжности, это отчасти везение, основанное на общем свойстве простоты. Иногда для того, чтобы сделать лучше, нужно просто стоять на месте там, где все бегут не туда.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Декабрь, 2020 04:55 
Аватара пользователя

Зарегистрирован: Среда, 22 Апрель, 2015 23:51
Сообщения: 248
Откуда: г. Рига, Латвийская ССР
Comdiv писал(а):
Но без усложнения языка оптимального определения не достичь.


...А усложнение языка опять приводит к понижению надёжности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Декабрь, 2020 14:37 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Не обязательно. Попробуйте, например, на фортоподобном языке, который куда проще Оберона, достичь той же надёжности при прочих равных. Надёжность программ - это не то явление, которое так примитивно зависит от простоты языка.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Декабрь, 2020 15:21 
Аватара пользователя

Зарегистрирован: Среда, 22 Апрель, 2015 23:51
Сообщения: 248
Откуда: г. Рига, Латвийская ССР
А никто и не говорит, что оно примитивно зависит от простоты языка. Просто в каждом изменении есть обе тенденции. Любое изменение одновременно усложняет и упрощает, делает более надёжным и менее надёжным. Важно установить правильную меру, а для этого нельзя закрывать глаза ни на одну из тенденций.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Декабрь, 2020 15:40 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Можете тогда рассказать, как усложнение языка добавлением дополнительных требований проверок задания значений может понизить надёжность?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2021 09:26 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2021 10:47 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Часть проверок, которые можно выполнять без изменений языка, ценна - и реализуема на каком-то отдельном уровне (как в попытке DevAnalyzer). Это хорошая мысль - реализовывать не в конкретном компиляторе, а отдельно.

Просто задача занудная, не сулящая прикладных прорывов - и никто особо не занимается.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2021 14:39 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Info21 писал(а):
Comdiv писал(а):
Можете тогда рассказать, как усложнение языка добавлением дополнительных требований проверок задания значений может понизить надёжность?
Разве компилятор не усложняется?
Тут возникают противонаправленные движения, баланс выяснить нелегко.
О том и речь, что язык и компилятор усложняются, а надёжность кода только растёт. Если задать этот же вопрос про средства работы с памятью и контроль её целостности, каков будет ответ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2021 14:51 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Илья Ермаков писал(а):
Часть проверок, которые можно выполнять без изменений языка, ценна - и реализуема на каком-то отдельном уровне (как в попытке DevAnalyzer). Это хорошая мысль - реализовывать не в конкретном компиляторе, а отдельно.
Такие анализаторы должны быть частью компилятора, хотя и не обязательно буквально, а в том смысле, что компилятор имеет результат статических проверок. С точки зрения достижения надёжности это важно потому, что частая причина отказа от проверок на ошибки - это дороговизна проверок во время исполнения, поэтому критично важно не проверять во время работы программы то, что выполняется априори. Это позволяет сократить количество проверок времени исполнения, уменьшить накладные расходы, и отказаться от тупого выключения проверок.

Пример отрицательных плодов погони за скоростью:
adimetrius писал(а):
Использование SHORT для усекновения старших разрядов - мелкое хулиганство, я полагаю; но, увы, в ББ оно повсеместно ((( Я частенько спотыкался об него, поскольку компилирую всегда со всеми включенными проверками; стоит перекомпилировать разок штатный модуль - и он начинает сыпаться


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2021 15:31 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2021 16:02 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Для ответа на этот вопрос(?), можно ответить на другие вопросы:
1. Компилятор, который вставляет код проверок выхода за границы массива проще или сложней того, который не вставляет? Как это влияет на надёжность?
2. Компилятор, который не проверяет никакие возможные ошибки в исходном коде и работает только для корректного кода, проще или сложней того, который проверяет? Как это влияет на надёжность?
3. Компилятор Форта проще или сложней компилятора Оберона? Как это влияет на надёжность?
...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2021 17:10 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Каждый раз надо смотреть особо, об этом речь.


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

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


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

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


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

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