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

Ответ на »сообщение 1519« (pepper)
___________________________
Число подозрительных мест невелико, если ловить утечки не таскменеджером, а чем-то более специализированным.
А может - ну его на фиг? :о) Может, лучше причину проблемы изничтожить, в смысле "профилактика лучше и дешевле, чем лечение"?


Речь шла не о выборе GC vs ручное управление памятью. Наивно полагать, что использование упоминавшийся реализации GC для C/C++ решит все проблемы с утечками, тем более в таких запущенных случаях как у вас в конторе.


GC не решает всех проблем с памятью, тем более в C/C++. Возьми хотя бы факт существования слабых (weak) указателей в языках с GC.
Не просветите?... У меня великое подозрение, что вы приведёте достаточно частную "реализацию" в системе, которая пыжится "скрестить ужа с ежом"... :о)


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



Очередь сообщений с их последующей обработкой без задействия GC.
Заранее нужное количество выделяете и используете кольцевой буфер.


Изначально вопрос возник как попытка выяснить преимущество для этой задачи оберона. Кольцевой буфер можно и на C наколбасить.


Си на Юникс-подобных ОСях: хотите меньше неприятностей с утечками памяти и висячими указателями? - не используйте *alloc/free... :о))) Тем более, что сама идеология Юникса построения многоэтапной обработки этому способствует... :о)

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

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

Ответ на »сообщение 1519« (pepper)
___________________________
Можно использовать буфер с явным возвратом в него ненужных более объектов-сообщений.Объекты будут динамические, но нагрузки на GC не будет.

Можно. А в чем тогда бужет преимущество оберона?

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

Ответ на »сообщение 1461« (pepper)
___________________________
И как организовать банальную очередь из таких записей?
Может так:

  TYPE
      Node = POINTER TO RECORD
        key: INTEGER;
        next: Node
      END;

    PROCEDURE AddNode (VAR list: Node; node: Node);
    BEGIN
      ...
    END AddNode;


И чего с этим делать? Как это будет работать без NEW?

Ответ на »сообщение 1522« (Илья Ермаков)
___________________________
А можно не в PDF а в чем-то что можно не только печатать но и почитать, например на покете?

Ответ на »сообщение 1520« (Илья Ермаков)
___________________________
Выполняю обещание, данное несколько дней назад - рассказать об архитектурных приемах, используемых в Оберонах.
См. http://blackbox.metasystems.ru/index.php?option=com_content&task=blogcategory&id=1&Itemid=5
статья "Некоторые идеи архитектуры Оберон-систем".

Ответ на »сообщение 1519« (pepper)
___________________________
Число подозрительных мест невелико, если ловить утечки не таскменеджером, а чем-то более специализированным.
А может - ну его на фиг? :о) Может, лучше причину проблемы изничтожить, в смысле "профилактика лучше и дешевле, чем лечение"?

Если все настолько запущенно, что непонятно отчего такое происходит, то такой код или переписывается нафиг или рефакторится.
Это, когда это позволительно делать. А если как в моём случае: "ты должен всё это исправить, но ничего не переделывай!"... :о)

GC не решает всех проблем с памятью, тем более в C/C++. Возьми хотя бы факт существования слабых (weak) указателей в языках с GC.
Не просветите?... У меня великое подозрение, что вы приведёте достаточно частную "реализацию" в системе, которая пыжится "скрестить ужа с ежом"... :о)

Очередь сообщений с их последующей обработкой без задействия GC.
Заранее нужное количество выделяете и используете кольцевой буфер.
Тем более, что обычно сама природа организации обмена через "сообщения" подразумевает не сильную нагрузку объёмами данных на элементы сообщений...

Хотите в качестве бреда?: один из выводов, сделанных мной из опыта работы с Си на Юникс-подобных ОСях: хотите меньше неприятностей с утечками памяти и висячими указателями? - не используйте *alloc/free... :о))) Тем более, что сама идеология Юникса построения многоэтапной обработки этому способствует... :о)

Ответ на »сообщение 1519« (pepper)
___________________________
Можно использовать буфер с явным возвратом в него ненужных более объектов-сообщений.Объекты будут динамические, но нагрузки на GC не будет.

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

И каким числом подозрительных мест Вы намерены ограничиться?


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


А если у Вас не утечка памяти, а напротив -- "виснут" указатели?


Если все настолько запущенно, что непонятно отчего такое происходит, то такой код или переписывается нафиг или рефакторится.


Вообще-то, "последним писком" (в поисках утечек памяти в программах на Си/Си++) вроде бы считается использование боэмовского (консервативного) сборщика мусора:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html
И почему бы тогда просто не пользоваться языком со сборкой мусора (в основном прецизной)?


GC не решает всех проблем с памятью, тем более в C/C++. Возьми хотя бы факт существования слабых (weak) указателей в языках с GC.



И как организовать банальную очередь из таких записей?
Я не совсем понял: Вы хотите организовать очередь из стековых объектов?


Очередь сообщений с их последующей обработкой без задействия GC.

Ответ на »сообщение 1461« (pepper)
___________________________
И как организовать банальную очередь из таких записей?
Может так:

  TYPE
      Node = POINTER TO RECORD
        key: INTEGER;
        next: Node
      END;

    PROCEDURE AddNode (VAR list: Node; node: Node);
    BEGIN
      ...
    END AddNode;

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


>>Вам когда-нибудь приходилось вылавливать утечки памяти в чужом Си++ном коде?

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


Какой дивный оптимизм! :)
И каким числом подозрительных мест Вы намерены ограничиться?
А если у Вас не утечка памяти, а напротив -- "виснут" указатели?
Вообще-то, "последним писком" (в поисках утечек памяти в программах на Си/Си++) вроде бы считается использование боэмовского (консервативного) сборщика мусора:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html
И почему бы тогда просто не пользоваться языком со сборкой мусора (в основном прецизной)?


>>Однако, слово "статические" здесь и правда неудачно.
Речь идет о том, что записи могут быть не только "динамическими" (в куче).
В частности, могут быть "автоматическими" (т.е. располагаться на стеке).

И как организовать банальную очередь из таких записей?

Я не совсем понял: Вы хотите организовать очередь из стековых объектов?
(Видимо, речь идет о реализации не с помощью массива, а с помощью указателей?)