Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 1566 10-01-2007 04:42 | |
Ответ на »сообщение 1557« (pepper)
___________________________
Ну хоть это не пришлось доказывать и на том спасибо :)
Хамите, парниша...
Но это всего лишь эвристика. Применяется, когда недоступно точное решение.
Ну, наверное, надо было слово эвристика в кавычки взять. Но зачем тут "эвристика" нужна, когда есть адекватное выражение логики работы через положение объекта-хранителя инфы для клиента в "кольце"?
Нет. Клиент получил свой объект и сервер больше о нем ничего знать не хочет.
У вас противоречие в постановке задачи. Или вы никак не оформитесь с формулировкой...
Вы перекладываете на общесистемный механизм семантическую нагрузку, чуждую ему: логику отслеживания занятости вашего объекта-"буфера" и логику решения, как поступать с "кэшем" поступать при поступлении запроса на создание нового объекта-хранителя...
Ты сознательно покоцал часть моего объяснения? Я там явно указал, что нет смысла чистить из кэша ссылку на объект (даже если он ну очень "давний"), который используется какими-то из клиентов, потому что этот объект все равно живет и занимает свою память.
А зачем мне чистить объект, который "используется каким-то из клиентов"?????
P.S. Кстати, на C++ эта задача тоже элементарно решается через смарт-поинтеры. Так что предлагает оберон (помимо внеязыковых манипуляций с GC и системой рантайма)?
Элементарно? Хе-хе...
Не ответите вопрос о возникновении необходимости введения-выдумывания механизма смарт-поинтеров в Си++ :о)
№ 1565 10-01-2007 04:38 | |
Ответ на »сообщение 1563« (AVC)
___________________________
Все бы хорошо, но всплывают старые проблемы, вроде кольцевых структур (к объектам уже нет доступа, но и удалить их не получается).
А тут все опять упирается в культуру программирования. Если тупо не лепить везде shared_ptr, а немного подумать и выбрать более подходящий смартпоинтер (тот же scoped_ptr), то проблема с кольцевыми структурами выявится еще на этипа компиляции.
№ 1564 10-01-2007 04:31 | |
Ответ на »сообщение 1562« (Сергей Губанов)
___________________________
Ну вот, как я и предполагал, внеязыковое средство...
Объекты слабых указателей тоже внеязыковое средство.
Ты про что?
P.S. Под языковыми средством я понимаю средствами, которые описаны в документации к языку (в тех самых 30 страницах или сколько там у оберона). Иначе все упоминания простоты языка в силу такого малого количества документации теряют смысл. Не говоря уже о переносимости и т.п. вопросах.
№ 1563 10-01-2007 04:27 | |
Ответ на »сообщение 1557« (pepper)
___________________________
P.S. Кстати, на C++ эта задача тоже элементарно решается через смарт-поинтеры. Так что предлагает оберон (помимо внеязыковых манипуляций с GC и системой рантайма)?
Насчет "элементарности" решения -- перегиб.
"Умные указатели" работают, как правило, на основе подсчета ссылок и удаляют объекты, для которых счетчик обнулился.
Все бы хорошо, но всплывают старые проблемы, вроде кольцевых структур (к объектам уже нет доступа, но и удалить их не получается).
Вот и приходится на каждый умный указатель громоздить еще более умный указатель (те же слабые указатели, например).
№ 1562 10-01-2007 04:25 | |
Ответ на »сообщение 1558« (pepper)
Ну вот, как я и предполагал, внеязыковое средство...
Объекты слабых указателей тоже внеязыковое средство.
№ 1561 10-01-2007 04:24 | |
Ответ на »сообщение 1555« (AVC)
___________________________
Вместе с тем, техника работы с "умными указателями" в Си++ приводит к довольно быстрому размножению сущностей.
Эти сущности декларируют разный смысл указателей. Глядя на такую декларацию (использование того или иного типа смартпоинтера) можно делать выводы о том "как это работает". Соответственно количество выводов, которые можно однозначно сделать, глядя на безликий поинтер в обероне, намного меньше.
№ 1560 10-01-2007 04:22 | |
Ответ на »сообщение 1558« (pepper)
___________________________
Ответ на »сообщение 1556« (Сергей Губанов)
___________________________
>>используется возможность предоставляемая модулем Kernel отыскать в памяти созданный ранее, но ещё не уничтоженный объект).
Ну вот, как я и предполагал, внеязыковое средство...
Так ведь не зря Оберон -- рефлексивный язык. :)
В отличие от Си++, например.
№ 1559 10-01-2007 04:19 | |
Ответ на »сообщение 1538« (pepper)
На моей практике часто возникает необходимость в процессе обработки одного сообщение добавить в очередь другое. Как "обобщённая транспортная шина передачи сообщений в оберонах" позволяет этого избежать?
В чью очередь? В очередь сообщений к себе самому, что ли? Вы самому себе сообщение хотите послать?
Если нужно что-то сделать, но сделать это нужно не прямо сейчас, а чуток погодя, то используйте следующее:
Services.DoLater (a: Services.Action; notBefore: LONGINT);
CONST immediately
Это значение может быть передано в DoLater параметром notBefore, если действие должно быть выполнено как часть команды, выполняющейся в настоящий момент.
CONST now
Это значение может быть передано в DoLater параметром notBefore, если действие должно быть выполнено как можно быстрее после текущей выполняемой команды.
№ 1558 10-01-2007 04:14 | |
Ответ на »сообщение 1556« (Сергей Губанов)
___________________________
используется возможность предоставляемая модулем Kernel отыскать в памяти созданный ранее, но ещё не уничтоженный объект).
Ну вот, как я и предполагал, внеязыковое средство...
№ 1557 10-01-2007 04:12 | |
Ответ на »сообщение 1553« (Владимир Лось)
___________________________
Для кого очевидный? Это полный бред – посвящать клиентов в работу сервера...
Ну хоть это не пришлось доказывать и на том спасибо :)
Эта самая эвристика – как раз часть твоей задачи.
Но это всего лишь эвристика. Применяется, когда недоступно точное решение.
Слежение (каким-либо способом) за "подключённостью" клиента к серверу у тебя есть?
Нет. Клиент получил свой объект и сервер больше о нем ничего знать не хочет.
Само положение "кешированного" буфера( объекта для клиента) уже говорит о давности его использования... При чём тут "слабые указатели"?
Ты сознательно покоцал часть моего объяснения? Я там явно указал, что нет смысла чистить из кэша ссылку на объект (даже если он ну очень "давний"), который используется какими-то из клиентов, потому что этот объект все равно живет и занимает свою память.
P.S. Кстати, на C++ эта задача тоже элементарно решается через смарт-поинтеры. Так что предлагает оберон (помимо внеязыковых манипуляций с GC и системой рантайма)?
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|