Владимир Лось писал(а):
Vlad писал(а):
А можно по-подробнее? Что за проблема с инициализацией локальных указателей и почему надо что-то лочить?
Потому, что между выделением фрейма стека для вызываемой функции и заполнением в нём всех локальных, для этой функции, указателей нулями может проснуться сборщик мусора...
Я не понимаю какое отношение это имеет к C++, пусть даже и с прикрученным к нему GC? Ну лежит в стэке мусор, самое худшее что может случиться - какой-нибудь объект "случайно" останется живым. В BB с его консервативным GC можно то же самое наблюдать.
Владимир Лось писал(а):
У меня же проблема была прямо противоположная: объект может быть уничтожен (в системе поддержки времени исполнения Си++), а ссылка на него (через цепочку контекстов вызванных функций из активности этого объекта) ещё "жива".
Не понял. Как GC умудряется прибить объект, если ссылка на него (через цепочку контекстов или как угодно) еще жива?
Владимир Лось писал(а):
То есть, менеджер памяти Си++ (условно говоря!) уже считает все поля, занимавшееся экземпляром свободными, а в системе поддержки многопотоковости мне ещё нужно обращаться к полям этого объекта...
В такой формулировке - это очень странное желание обращаться к полям удаленного объекта.
Владимир Лось писал(а):
На boost или ACE "решения" прошу не указывать. Там - не то, что мне надо. Я хотел полностью влить синтаксис АО в Си++. Не получилось. В смысле синтаксис-то я обеспечил, но семантика "поплыла". Да что там поплыла? - на Си++ просто НЕЛЬЗЯ АО-подобные активные объекты получить. Только - обрезки и обёртки а ля указанные библиотеки.
Ну и зачем вам
копия синтаксиса AO? Суть концепций AO замечательно выражается на C++. Да, форма будет немного другая, зато родная для C++. Глядишь и с GC тогда не будет проблем (хотя лично я бы очень сильно подумал, прежде чем прикручивать к C++ GC).