OberonCore

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

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




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

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


Вот именно - в общем случае никак не избежать. Ненулевые ссылки вводят частный случай (который на практике встречается намного чаще, чем общий), в котором такая проверка просто ненужна. Раз ненужна - значит ее нельзя забыть сделать, она просто ненужна :) Мало того, для общего случая компилятор теперь может заставить эту проверку сделать. Без введения ненулевых ссылок заставлять каждый раз проверять ссылку - крайне непрактично (также как и заставлять проверять индекс перед каждым обращением к массиву).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 00:07 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Владимир Лось писал(а):
Дайте кода!


Вы же вроде писали на C++? Тогда я не понимаю, почему у вас такие трудности с пониманием этой идеи. Вот смотрите:
Код:
form_t &make_form(database_t &);


Из этого кода видно, что я не могу создать форму для нулевой базы данных. Все бы хорошо, но проблема C++ в том, что таки получить на практике нулевую ссылку не так сложно (что правильно заметил Alexey Veselovsky) - достаточно написать '*' для нулевого указателя.
Код:
database_t *db = connecto_to_database(); // если с базой что-то страшное - возвращается NULL
make_form(*db); // Все, приплыли, AV обеспечен


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

Код:
database_t *db = connecto_to_database();
if(database& d = not_null_cast(db))
    make_form(d); // здесь ссылка всегда корректна
else
   // обработка ситуации, когда база нулевая


Наличие этой конструкции (if/not_null_cast) контролирует компилятор, вы не можете просто написать "make_form(not_null_cast(db))". В случае оберона мне кажется, что WITH вполне подходит для этой цели. До тех пор, пока OPTIOAL ссылка не прошла WITH с превращением в обычную (ненулевую) - с ней ничего нельзя делать, только передавать как аргумент или возвращать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 00:21 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
т.е. вместо c-style cast'a (молчаливого разыминовывания *p_a) ввести два других: not_null_cast и possible_null_cast ?

Причем not_null_cast будет иместь скажем синтаксис аналогичный try{} catch{}, или же просто будет уметь кидать исключение, которое потом всё равно ловить тем же try-catch'em, впрочем, так оно вроде в Аде и делается ;-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 06:55 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Info21 писал(а):
Может, лучше задаться вопросом, почему переменные INTEGER и т.п. не имеют значения UNDEFINED.

Разве не имеют? А переполнения? Это же потеря информации, т.е. тот же самый UNDEFINED...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 07:28 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Trurl писал(а):
Geniepro писал(а):
Затем, при обработке таких "объектов" программист обязан рассмотреть оба случая -- когда нет значения, и когда оно есть.

Кому это он обязан? И что будет, если он не рассмотрит один из случаев?

Вообще, зависит от реализации.
Компилятор Хаскелла GHC пропустит, но при выполнении программа упадёт, однако если компилировать с опцией -Wall то при компиляции будет выдано сообщение о пропущенной обработке каких-либо конструкторов этого типа.
Компилятор F# просто откажется компилировать такую программу, пока программист не рассмотрит все случаи (в данном примере и Some x, и None)...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 07:37 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Владимир Лось писал(а):
Дайте кода!

Ну вот простенькое на F#:
Код:
match dbase.TryFind value with
| Some x -> // что-то нашли, обработаем
| None   -> // ничего не нашли, наверное ошибка! по-другому обработаем

Аналогично в Хаскелле...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 08:21 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Geniepro писал(а):
Info21 писал(а):
Может, лучше задаться вопросом, почему переменные INTEGER и т.п. не имеют значения UNDEFINED.

Разве не имеют? А переполнения? Это же потеря информации, т.е. тот же самый UNDEFINED...

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

Так ша - мимо...

Geniepro писал(а):
Владимир Лось писал(а):
Дайте кода!

Ну вот простенькое на F#:
Код:
match dbase.TryFind value with
| Some x -> // что-то нашли, обработаем
| None   -> // ничего не нашли, наверное ошибка! по-другому обработаем

Аналогично в Хаскелле...


Ну объясните мне чем это от классических проверок отличается?
Ну я буду просто результатом TryFind в классике возвращать ПУСТО или ссылку на кортеж считанных значений - я всё равно проверю перед использованием...

Vlad писал(а):
XXX_cast

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 09:26 

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


Видите-ли, преимущества данного подхода проявляются прежде всего на больших задачах. Потому что на маленьких вы всегда видите откуда что пришло, и может даже не забудете написать if (p). Чем вам не угодил пример с БД и формой? Повседневная рутина.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 12:18 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Владимир Лось писал(а):
Ну объясните мне чем это от классических проверок отличается?
Ну я буду просто результатом TryFind в классике возвращать ПУСТО или ссылку на кортеж считанных значений - я всё равно проверю перед использованием...

Тем, что заставляет компилятора дополнительно контролировать действия программиста.
Вы, может быть, и проверите -- и то не факт, ибо от запарок никто не застрахован -- а кто другой точно забудет проверить!
А компилятор напомнит...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 13:09 

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье
Valery Solovey писал(а):
Я, конечно, не работал с РВ, но мне кажется, что совмещение освобождения памяти и создания нового объекта будет гораздо меньше, чем у сборщика и относительно небольшим по сравнению с ручным освобождением памяти. Под совмещением я подразумеваю немедленное автоматическое освобождение памяти при указании ссылки на новый объект (и если счётчик ссылок на объект обнулён). Самое важное для РВ - предсказуемость? Ну так здесь всё предсказуемо.

PS. Это решение в лоб. Возможно, найдётся что-то и получше.

Здесь интересно написано о сборщике мусора в Эрланге (soft real-time).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 16:31 

Зарегистрирован: Вторник, 20 Ноябрь, 2007 10:45
Сообщения: 28
Просто мысли вслух по поводу нулевых ссылок:
Если в языке насильно убрать открытые свойства (property) классов и оставить только открытые методы, а также если ввести в сигнатуру методов данные о типах выбрасываемых исключений, а также если ввести правило что любой метод любого класса/протокола всегда может выбросить исключения типа Exception, т.е. описание метода класса будет примерно таким:
Код:
interface SomeProto
{
   public int someFunction(/* params */) throws Exception, OtherException;
}


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 18:29 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
MaximGB писал(а):
То тогда runtime языка при вызове метода от нулевой ссылки (указателя) может смело генерировать исключение типа Exception, а программист в свою очередь будет обязан его обработать, так как тип исключения описан в сигнатуре метода.


И что, любое обращение по ссылке оборачивать в try/catch? :) И в страшном сне не приснится :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 18:33 

Зарегистрирован: Вторник, 20 Ноябрь, 2007 10:45
Сообщения: 28
Вполне нормально, есть некий блок кода, в котором известно что могут быть выброшены исключения, например, 3-х типов - Exception, InvalidDataException, CommunicationException. При условии что InvalidDataException и CommunicationException потомки Exception, а также что эти исключения не требуют некой доп. обработки, то отлавливать надо только Exception и не на каждое обращение к ссылке, а не весь блок сразу
Код:
try {
   // 10 - 15 строк кода
}
catch (Exception e) {
   // Обработка
}


Ничего страшного


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 29 Январь, 2009 19:02 

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


Идея не в том, чтобы поймать исключение при обращении к нулевой ссылке, а в том, чтобы вообще не допустить такой ситуации как обращение по нулевой ссылке. То, что вы тут показали (явная спецификация исключений) уже и так есть в жабе. Толку то? Ну поймали вы этот "null dereference exception", что дальше с ним делать будете? Прокините из своей подсистемы выше? Обработаете и превратите в исключение своей подсистемы и прокините дальше? Скушаете и попытаетесь продолжить работу? В любом случае - это ошибка, которая проявляется только в рантайме, и с которой вам придется иметь дело при разработке своей подсистемы. А всего этого можно избежать просто отменив нулевые ссылки :)

P.S. В жабе определенные классы исключений (в том числе и этот самый "null dereference exception") компилятор не заставляет ловить. Иначе у вас практически любой код будет или обернут в try/catch или задекларирован как кидающий "null dereference exception". Непрактично это.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Январь, 2009 16:07 
Аватара пользователя

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

А можно на примере узнать как "отменяются" нулевые ссылки? Вот у меня есть список:
Код:
  TYPE
    Item = POINTER TO RECORD
        value: INTEGER;
        next: Item
      END;

  VAR
    first, last: Item;

  PROCEDURE Put* (value: INTEGER);
    VAR item: Item;
  BEGIN NEW(item); item.value := value;
    IF last # NIL THEN last.next := item ELSE first := item END;
    last := item
  END Put;

  PROCEDURE Get* (OUT value: INTEGER; OUT ok: BOOLEAN);
  BEGIN
    IF first # NIL THEN
      value := first.value; ok := TRUE; first := first.next;
      IF first = NIL THEN last := NIL END
    ELSE
      value := 0; ok := FALSE
    END
  END Get;

И как "отменить" нулевые ссылки?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Январь, 2009 16:21 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Сергей Губанов писал(а):
Vlad писал(а):
А всего этого можно избежать просто отменив нулевые ссылки :)

А можно на примере узнать как "отменяются" нулевые ссылки? Вот у меня есть список:
Код:
  TYPE
    Item = POINTER TO RECORD
        value: INTEGER;
        next: Item
      END;

  VAR
    first, last: Item;

  PROCEDURE Put* (value: INTEGER);
    VAR item: Item;
  BEGIN NEW(item); item.value := value;
    IF last # NIL THEN last.next := item ELSE first := item END;
    last := item
  END Put;

  PROCEDURE Get* (OUT value: INTEGER; OUT ok: BOOLEAN);
  BEGIN
    IF first # NIL THEN
      value := first.value; ok := TRUE; first := first.next;
      IF first = NIL THEN last := NIL END
    ELSE
      value := 0; ok := FALSE
    END
  END Get;

И как "отменить" нулевые ссылки?


Просто будет на ряду с first, last, ещё и магический элемент empty. Эдакий типизированный нуль. Т.о. строчка
Код:
IF first = NIL THEN last := NIL END


преобразуется в строчку:
Код:
IF first = empty THEN last := empty END


Причем этот самый empty должен быть константой.
Так, кстати, крайне рекомендуют делать в джаве, чтобы у ссылок null небыло никогда.

PS. Кстати, а где инициализация first, last нулём? В КП (т.е. вне зависимости от реализации) это делается автоматически?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Январь, 2009 16:38 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
Alexey Veselovsky писал(а):
PS. Кстати, а где инициализация first, last нулём? В КП (т.е. вне зависимости от реализации) это делается автоматически?

No comments...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Январь, 2009 16:47 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Владимир Лось писал(а):
Alexey Veselovsky писал(а):
PS. Кстати, а где инициализация first, last нулём? В КП (т.е. вне зависимости от реализации) это делается автоматически?

No comments...

No comments.


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Alexey Veselovsky писал(а):
Владимир Лось писал(а):
Alexey Veselovsky писал(а):
PS. Кстати, а где инициализация first, last нулём? В КП (т.е. вне зависимости от реализации) это делается автоматически?
No comments...
No comments.
Если уж не доки, то читайте хотя бы форум, Алексей.


Последний раз редактировалось Александр Ильин Пятница, 30 Январь, 2009 17:10, всего редактировалось 1 раз.

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

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

Зачем?


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

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


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

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


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

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