2 Илья Ермаков
Немного не "в тему", но не могу удержаться.
Почитал материалы на metasystems.ru по Оберон-технологиям, статьи Дейкстры и т.д. Получил огромное удовольствие, особенно от "Дейкстры". Такое впечатление, что он это вчера написал :) Особенно, про то "промывание мозгов", которое происходит в информатике и программировании. Про Обероны у него ни слова, но такое впечатление, что их "дух" присутствует в каждой строке. Спасибо за публикацию.

Ответ на »сообщение 1543« (pepper)
___________________________
Причем тут шаблоны? Каким образом логика этапа компиляции может быть применена для выбора варианта действий в зависимости от динамического типа переменной?
typeid Вам тоже мало поможет... switch по нему сделаете? И что же дальше?
Если сообщение будет иметь расширенный тип, то typeid будет другим, и switch с typeid типа-предка его не обработает, в отличие от WITH в Обероне.
Только dynamic_cast и годится.

Приведите "более элегантный" пример эквивалентный по своей логике - двойная виртуализация по (TYP(object), TYP(message)) на этапе выполнения? Если все типы уже существуют на этапе компиляции, то есть красивый способ, предложенный в книге Дж. Элджера "С++ for real programmers" - двойная передача, когда сначала выявляется динамический тип второго параметра вызовом obj->Handle(msg), а затем идет "обратная подача" msg->Handle(obj), т.е. индексирование идет неявно по двум v-таблицам. Однако требуется описывать декартово произведение виртуальных функциий в обоих типах. Расширить систему на этапе выполнения принципиально невозможно. Ничего другого, лучшего "дубового WITH", Вам не придумать.

Про LPARAM/WPARAM молчу. Кто-то тут воевал за "адекватные структуры данных". Если INTEGER вместо перечислений не катит, то чем катит INTEGER вместо RECORD? :-)

Кстати, об Элджере. Два года книжку эту с полки не брал. Читал еще до знакомства с Оберонами. Открыл сегодня - увидел касательно архитектуры ООП те же идеи, что я описал в своей статье про Обероны: гомоморфные иерархии классов, "инкапсулируйте классы-расширения - это признак хорошо продуманной архитектуры" и т.п. Так что и в С++ приходим к тем же ограничениям, только долгим путем через такое место, через которое ходить особо не хочется... :-) И навязать эти ограничения начинающим самоуверенным самоучкам крайне сложно, потому что "язык позволяет, свободу программисту, никаких ограничений"...

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

Ответ на »сообщение 1542« (Илья Ермаков)
___________________________

Что касается жабы и шарпа, то там можно использовать int + массив заранее распределенных сообщений (хотя есть подозрение, что в шарпе есть более подходящие средства).


Хотя int не учтет случаи наследования сообщений и вообще некошерен. В таком случае оберон может дать фору жабе/C# в случае описанного свитча по типам сообщения. Но хотелось бы услышать мнение эксперта в этих языках.

Ответ на »сообщение 1542« (Илья Ермаков)
___________________________

Во-первых, система GUI-сообщений в Оберонах построена на сообщениях, размещаемых в стеке, как и писал Сергей. Читайте мою статью по архитектуре, ссылка была ранее.


Ну если речь идет только лишь о самих сообщениях, то я не вижу здесь каких-то открытий. Виндовые LPARAM и WPARAM тоже все из себя "статические" и "обощенные" ;) Причем работают в старом добром C ;) В C++ помимо тормозного dynamic_cast есть шаблоны и typeid, так что до такого дубового свитча по типам дело, как правило, не доходит (ищутся более элегантные решения). Что касается жабы и шарпа, то там можно использовать int + массив заранее распределенных сообщений (хотя есть подозрение, что в шарпе есть более подходящие средства).

Ответ на »сообщение 1536« (pepper)
___________________________
Во-первых, система GUI-сообщений в Оберонах построена на сообщениях, размещаемых в стеке, как и писал Сергей. Читайте мою статью по архитектуре, ссылка была ранее.
Естественно, сделать очередь из стековых или статических сообщений невозможно, но зачем? Если действительно нужно, то чем плоха динамика?
В последней русской версии ББ мы предоставили спец. средство - Mem.Heap, которое предоставляет буферизацию для этих целей. Преимущество перед обычной неуправлямой кучей все равно остается - утечки памяти невозможны. Если забудем вернуть объект в буфер, его подберет обычный сборщик.

Ответ на »сообщение 1540« (pepper)
___________________________
Тяжко с вами, pepper...

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


В случае с Си++ (в общем случае) ничего не решит всех проблем с утечками.


В общем случае не решит. В частном случае, проблема с утечками может быть решена и без GC.


Это достаточно общая проблема для языков с GC.
?


GC не овобождает полностью от проблем с утечками. Просто утечки становятся более другие. Здесь пролетала ссылка с разъяснениями применительно к Java.

Ответ на »сообщение 1526« (pepper)
___________________________
Речь шла не о выборе GC vs ручное управление памятью. Наивно полагать, что использование упоминавшийся реализации GC для C/C++ решит все проблемы с утечками, тем более в таких запущенных случаях как у вас в конторе.
Речь о моей конторе вообще не шла.
В случае с Си++ (в общем случае) ничего не решит всех проблем с утечками.

Это достаточно общая проблема для языков с GC.
?

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

Изначально вопрос возник как попытка выяснить преимущество для этой задачи оберона. Кольцевой буфер можно и на C наколбасить.
Какой задачи?
И какое отношение она имеет к конкретному языку ОберонХХХ?
А кто, находясь в здравом уме, будет "насильничать" над менеджером памяти, постоянно выделяя и возвращая системе блоки памяти при динамическом обслуживании клиентов при message passing-е???????

Когда речь идет о C++, независимо от используемой ОС, все проблемы с ручным управлением памятью решаются через смарт-поинтеры. Соответственно ни о каких  free/delete речь не идет.
Какой вы оптимист. Ваш оптимизм оправдан, когда всё управление ресурсами зависит только от вашей подсистемы. В обероне потому управление памятью и вынесено на уровень операционной системы, что иначе, вы надёжную систему ни с какими смарт-поинтерами (и прочими заклинаниями) не построите, если даже самый лучший механизм работает на уровне отдельного приложения!

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


1) Семантика обобщённой транспортной шины передачи сообщений в оберонах такова, что требует немедленной обработки сообщения. Следующее сообщение никогда не будет передано пока не будет завершена обработка предыдущего. О какой ещё очереди тут может идти речь?..


На моей практике часто возникает необходимость в процессе обработки одного сообщение добавить в очередь другое. Как "обобщённая транспортная шина передачи сообщений в оберонах" позволяет этого избежать?


2) Из объектов сообщений невозможно образовать очередь.


Вот и мне тоже так казалось.

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


Дорогой pepper, вы не излечимы. Вам нравится "более крутые" языки программирования?
Используйте на здоровье! А нам вот нравится мыслить категориями Оберонов. Работаем вот и не жалуемся, что нам того и сего не хватает.


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