OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 16 Октябрь, 2019 03:18

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




Начать новую тему Ответить на тему  [ Сообщений: 154 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 31 Январь, 2009 01:00 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
По тому, что здесь уже наговорено - ряд мыслев...
1) Проблема с предложением Vlad-ом подобного рода ссылок - в логической нестыковке правил на счёт областей видимости переменных и возможных (или необходимых) местах инициализации таких ссылок.


Согласен, есть такая проблема.

Владимир Лось писал(а):
2) В современных общеупотребительных императивных языках, ситуацию, максимально подходящую под идеи Vlad можно организовать ТОЛЬКО для случая, когда имеется какой-то набор статических данных, а на обработку они отправляются в процедуры с аргументами-ссылками... Почему - см. пункт 1.


Почему обязательно статических и почему именно в виде аргументов?
Код:
PROCEDURE make_data(): Data;


Эта функция всегда возвращает ненулевые данные сколь угодно динамические. Другой вопрос, что конкретно в обероне, ввиду отсутствия механизма исключений, таких функций на практике будет мало (если не перекладывать обработку всех ошибок на ASSERT'ы).

Владимир Лось писал(а):
3) Несколько дальше продвинулся на почве императивщины в направлении Vlad-овских мыслей язык Limbo. Там можно (по причине пересмотра синтаксиса и нотации) совмещать объявления с инициализацией... Собственно, Си/Си++ тоже поддерживает такой способ записи, но по причине 1 и 2 - никто всегда не будет этому следовать... Понятно, что в Обероне это в принципе нельзя ввести. Дело не в какой-то там "ущербности" оберонов... Работает опять-таки принцип "современного логического ассемблера ЯП-ия" : "всё делать явно!"... В том числе и - операции со ссылками...


Не понял. Почему совмещение "объявления и инициализации" несовместимо с "все делать явно"? Такой подход решает проблему из пункта 1. Но я намеренно не стал этого упоминать, чтобы сразу не отпугнуть здешнюю публику, которая как уже выяснилось негативно настроена к упразднению секции VAR :)


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Vlad писал(а):
Напишите код, при компиляции которого X::x останется непроиниченой.

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

Во-вторых, &-ссылку в С++ нельзя динамически изменять, т.е. для организации динамических структур (я о том примере со списком) её использовать нельзя.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Февраль, 2009 07:57 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Сергей Губанов писал(а):
Во-первых, это не будет доказательством чего-либо.


Вы придумали какую-то "теорию" несовместимую с практикой - вы ее и опровергайте.

Сергей Губанов писал(а):
Во-вторых, &-ссылку в С++ нельзя динамически изменять, т.е. для организации динамических структур (я о том примере со списком) её использовать нельзя.


Ну да, нельзя изменять. Как это связано с тем, что компилятор может гарантировать ее инициализацию? На том же С++ можно реализовать такой тип, который будет требовать явной инициализации (ненулевой ссылкой), но при этом его можно будет копировать. Показать на вашем примере со списком или просто поверите?


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Февраль, 2009 11:27 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Суть того, что предлагается, как я это понял:
сейчас - если некий объект забыли создать-подключить к указателю, то этот указатель может "заваляться" неопределённо долго времени, пока выяснится ошибка при обращении по нему, в другом месте-моменте-времени.
хотят - за счёт введения типа "ненулевой указатель" поймать его уже тогда, когда он будет засовываться на хранение, т.е. гораздо ближе к тому месту-моменту, где забыли указатель настроить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Февраль, 2009 11:38 

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


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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 03:03 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Axcel писал(а):
По моему это как раз тот случай. "Сильное" тестирование с массовым применением Assert мне кажется гораздо практичнее.


А зачем противопоставлять? Тестирование - хорошо. Лов ошибок на этапе компиляции - еще лучше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 03:36 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Info21 писал(а):
Впечатление, что проблема выеденного яйца не стоит.


Тем не менее, эта проблема намного актуальнее "правильных" циклов без break и т.п. циклов Дейкстры. Потому что "неправильный" цикл - это конкретный кусок кода, который можно переписать (если уж сильно не нравится). А вот искать из какой части системы пришла нулевая ссылка, или какая часть системы забыла проинициализировать эту ссылку, почему (представьте, что такое происходит только в результате обработки какой-то ошибки, типа открытия файла), и в результате какого изменения - занятие на неопределенное время.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 04:05 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Info21 писал(а):
и решение по делу -- строгая статическая типизация. А тут...


Ненулевые ссылки наряду с OPTIONAL можно рассматривать как дальнейшее усиление статической типизации.


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

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 09:50 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
В сложном случае Вы его даже не построите. У Вас такая работа, что этих сложных случаев нет.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 10:19 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Vlad писал(а):
Вы придумали какую-то "теорию" несовместимую с практикой - вы ее и опровергайте.

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

Vlad писал(а):
Ну да, нельзя изменять. Как это связано с тем, что компилятор может гарантировать ее инициализацию?

Ваш пример с ссылками в С++ не связан с динамически изменяемыми указателями.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 10:20 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Однозначно можно сказать только то, что компилятор обязан генерировать код инициализации указателей, в противном случае сборщик мусора обрушит систему при попытке разыменования мусорного значения неинициализированного указателя.

В случае многопоточной системы это может быть чуть-чуть нетривиально.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 11:43 
Аватара пользователя

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

Тем не менее, эта проблема намного актуальнее ...

Я говорил о другой проблеме.

Что правильность вводимых данных нужно жестко контролировать -- не вопрос.
А здесь речь фактически о том, что неправильными данными обмениваются сильноразделенные части программы: одна что-то неправильно генерит (видимо, цикл плохо написан 8)), а другая на правильность этих данных должна полагаться. Ну и что.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 15:47 

Зарегистрирован: Понедельник, 19 Март, 2007 09:40
Сообщения: 142
Откуда: USA, Israel, Belarus
Неужели "висячие указатели" или "выход за границы массива" -- это не ошибки в миллиард $ ?
На нулевых указателях любая система надежно падает, а другие ошибки большинство систем просто игнорируют.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 16:05 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
slava писал(а):
Неужели "висячие указатели" или "выход за границы массива" -- это не ошибки в миллиард $ ?
На нулевых указателях любая система надежно падает, а другие ошибки большинство систем просто игнорируют.


Не падает, а попадает в ловушку (trap) предназначенную именно для того чтобы аварийно завершить программу, если в алгоритме имеется ошибка. Недопустить непредсказуемой работы программы. Намного было бы ХУЖЕ, если бы программа при этом не падала, а продолжала работать.

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

Кстати, в моей практике программирования на С++ несколько раз были случаи когда из за неверного значения указателя программа не падала, а начинала работать "не так". Вызывались в частности функции совершенно не причастных к действу классов. Очень весело было на это дело в дебаге смотреть. ;-)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 16:32 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Сергей Губанов писал(а):
"Ненулевых ссылок" я не придумывал, "теорий" не изобретал.


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

Сергей Губанов писал(а):
Vlad писал(а):
Ну да, нельзя изменять. Как это связано с тем, что компилятор может гарантировать ее инициализацию?

Ваш пример с ссылками в С++ не связан с динамически изменяемыми указателями.


Ну и зачем вы поскипали то, что я написал дальше? Тогда еще раз: заводится "ссылка" а-ля ref<T>, требующая явной инициализации и изменяемая как угодно динамически. И ваш пример со списком замечательно переписывается на реальном языке с реальным контролем "ненулевости".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 16:45 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Info21 писал(а):
А здесь речь фактически о том, что неправильными данными обмениваются сильноразделенные части программы: одна что-то неправильно генерит (видимо, цикл плохо написан 8)), а другая на правильность этих данных должна полагаться. Ну и что.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Февраль, 2009 16:50 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
slava писал(а):
Неужели "висячие указатели" или "выход за границы массива" -- это не ошибки в миллиард $ ?
На нулевых указателях любая система надежно падает, а другие ошибки большинство систем просто игнорируют.


Висячие указатели и прочие выходы за границы - проблемы, успешно решенные практически всеми современными ЯП (собственно, кроме C/C++ никого и не осталось с такими проблемами). А вот проблема нулевых ссылок толком еще не решена. И именно ее мы обсуждаем.


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

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


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

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


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

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