OberonCore

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



Почему обязательно статических и почему именно в виде аргументов?


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



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

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

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

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



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

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

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

Ну хорошо, а если инициализация не правильна, не та база или не та таблица, или еще что-то. Здесь уже была тема по поводу тестирования (которое лучше сильный типизации). По моему это как раз тот случай. "Сильное" тестирование с массовым применением Assert мне кажется гораздо практичнее.

Забыть чего-то инициализировать -- неспецифичная ошибка в ряду всех прочих возможных ошибок построения алгоритмов и программ.

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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



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

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

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