Ответ на »сообщение 1560« (AVC)
___________________________

Ответ на »сообщение 1558« (pepper)
___________________________

Ответ на »сообщение 1556« (Сергей Губанов)
___________________________

>>используется возможность предоставляемая модулем Kernel отыскать в памяти созданный ранее, но ещё не уничтоженный объект).

Ну вот, как я и предполагал, внеязыковое средство...

Так ведь не зря Оберон -- рефлексивный язык. :)
В отличие от Си++, например.

Кстати, я вот читал те самые 16-30 страниц описания Оберона, и, честно говоря, рефлексивности в нем не заметил... Быть может слишком невнимательно читал... Т.е. не больше в нем рефлексивности чем скажем в С++, или (тем более) в расширения С++ от Борланда.

По поводу слабых указателей (weak pointers)...
1) Мне приходят на ум задачки, в которых они весьма и весьма полезны, однако это никак не кольцевые буфера...
По-моему, слабые указатели нужны в тех случаях, когда модуль-создатель желает сохранить связь с созданными объектами для выполнения каких-либо операций с ними. Т.е. созданные объекты регистрируются через weaks, пока они существуют и нужны кому-то снаружи, модуль-создатель обеспечивает для них какие-либо периодические фоновые сервисы (например, автоматическое проецирование в перманентное хранилище или рассылку широковещательных сообщений), как только объект стал не нужен, сборщик его спокойно подбирает, а сервис при очередном проходе обнаруживает нулевой weak-pointer и снимает объект с регистрации. Без мягких ссылок регистрация являлась бы якорем, и нам пришлось бы требовать от клиентов явно вызывать Close etc. для ненужных более объектов.
Именно в прицеле на подобного рода системные сервисы мы и ввели Weak Pointers в Active BlackBox - кстати, это довольно простой механизм и никаких особенных накладных расходов он не вызывает, не больше, чем финализаторы. У Рихтера в "Программирование под .NET" подробно описано...
2) Простите, а в каком языке слабые ссылки являются частью языка? В .NET, например, это также внеязыковое средство, особый класс Framework'а.

Ответ на »сообщение 1570« (pepper)
___________________________
Распиши подробнее свое решение. Только пожалуйста, перечитай еще раз постановку задачи.
А сколько у вас в лавке аналитикам и проектировщикам плотют?

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

Элементарно. Уж смартпоинтер даже студент накалякать сможет. Тетенек в расчет не берем.
Теперь бы ещё студент смог объяснить а на кой они ему, по большому гамбургскому счёту?... Или – шо б було?

Уход от ручного управления ресурсами (в том числе памятью) и временем жизни объектов.
Браво! :о)))))))))))))))))))))))))))))))

Ответ на »сообщение 1569« (Владимир Лось)
___________________________


Слушайте, pepper, а почему вы каждый раз идёте от средства реализации к задаче, а не наоборот???

Поясни, пожалуйста.

Ответ на »сообщение 1567« (Сергей Губанов)
___________________________


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

Опять пошли аналогии... Ну ладно, поддамся на провокацию. Проблема в том, что в химической промышленности используются вполне определенные химические соединения. И для того, чтобы что-то синтезировать из этих соединений товар народного потребления, знания одной таблицы Менделеева мало.

Ответ на »сообщение 1568« (Max Belugin)
___________________________
А если мы хотим не перебирвать все объекты а воспользоваться индексом/хешем?
(search_with_google()) ? use_found() : write_them_by_youself();
:o)

Ответ на »сообщение 1566« (Владимир Лось)
___________________________

Хамите, парниша...


Там стоит смайлик.


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


Распиши подробнее свое решение. Только пожалуйста, перечитай еще раз постановку задачи.


А зачем мне чистить объект, который "используется каким-то из клиентов"?????


Потому что память кончилась. А какие объекты все еще используются клиентами, а какие просто висят в кэше и не используются ни одним из клиентов, ты не знаешь.


P.S. Кстати, на C++ эта задача тоже элементарно решается через смарт-поинтеры. Так что предлагает оберон (помимо внеязыковых манипуляций с GC и системой рантайма)?
Элементарно? Хе-хе...


Элементарно. Уж смартпоинтер даже студент накалякать сможет. Тетенек в расчет не берем.


Не ответите вопрос о возникновении необходимости введения-выдумывания механизма смарт-поинтеров в Си++ :о)

Уход от ручного управления ресурсами (в том числе памятью) и временем жизни объектов.

Ответ на »сообщение 1557« (pepper)
-------------
Слушайте, pepper, а почему вы каждый раз идёте от средства реализации к задаче, а не наоборот???
Теперь становится ясна ваша позиция о "неприменимости" оберонов для "реальной жизни"!
Конечно, если плясать от ограничений языка, а не от решения задачи к выражению её в языке - тогда и Си++, в конечном итоге, "не хватит" и дотнетовских библиотек не напасёшься!

Ответ на »сообщение 1554« (Сергей Губанов)
___________________________
>>>В BlackBox есть следующая штука.

А если мы хотим не перебирвать все объекты а воспользоваться индексом/хешем?

Ответ на »сообщение 1564« (pepper)

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

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

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