Здравствуйте, Кодт, Вы писали:

К>Статический член был определён и в dll, и в exe. В результате — тот код, который имеет с ним дело внутри dll, обращается к своему экземпляру, а тот, который в exe — к своему.
Спасибо. Я так и думал. Хотелось уточнить догадку

D>>P.S. Кривое решение впринципе есть. Это делать данный map в головном exe, а dll давать на него ссылку.
К>"Ну, или так".
На самом деле все намного сложнее. CtdRefCount превратился в CtValues<void*, int>.
Есть глобальный пул фабрик классов, в нем просто зарегистрировали фабрику на CtdRefCount, а в Alloc SmartLink'a проверяем есть ли объет, нету тогда создаем его через пул фабрик. Ну и последний SmartLink убивает map если в нем нет элементов.

К>А ещё можно было вынести "службу подсчёта ссылок" в отдельную dll, в виде функций
К>

К>int addref(void* key);
К>int release(void* key);
К>

К>и пусть твои шаблоны пользуются этими функциями на здоровье.
В данном случае это не прокатит. Поскольку эту dll должен кто-то загрузить. А XML-парсер нужен моему CcApllication для чтения настроек при старте. Хм... правда можно эту либу статически прилинковать к exe. Ну да ладно, будет тормозить через фабрику тогда поковыряем.

К>Вообще, зачем делать такой странный подсчёт ссылок? Чем не понравился, к примеру, boost::shared_ptr?
Boost еще к Builder C++ 6 прикрутить надо. Пробывал stl::auto_ptr не прокатил, он убивал объект когда не него еще были другие ссылки. Ведь про другие stl::auto_ptr на тот же объект он ничего не знает и сносит объект, когда помирает сам.

К>Или очень нужна была интрузивность?
Что за зверь "интрузивность" ?

К>Кстати говоря, нужно быть очень аккуратным, когда делаешь внешний счётчик ссылок. Кастинг туда-сюда, и получаешь другое значение указателя на тот же самый объект.
Через фабрику проблем нет, всегда получаем что надо. Ибо ручками никаких кастов не делаем.