Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Поместить в одну DLL определения конкретных используемых специализаций, а из других — импортировать.
Да, похоже придётся так и сделать. А в идеале хотелось бы отнаследовать класс от CSingleton и получить свойства синглтона с минимальными добавками. А так придётся лезть в другую dll, чтобы объявить там экзэмпляр. Блин!
> ПК>Поместить в одну DLL определения конкретных используемых специализаций, а из других — импортировать.
> Да, похоже придётся так и сделать. А в идеале хотелось бы отнаследовать класс от CSingleton и получить свойства синглтона с минимальными добавками. А так придётся лезть в другую dll, чтобы объявить там экзэмпляр. Блин!
Можно не лезть в другую DLL, а делать это все в DLL, в которой определен класс, унаследованный от CSingleton.
Posted via RSDN NNTP Server 1.9 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Можно не лезть в другую DLL, а делать это все в DLL, в которой определен класс, унаследованный от CSingleton.
В таком случае как объявить m_pInst? С __declspec(dllimport)? Без этого каждая dll будет искать экземпляр у себя, а с этим dll с экземпляром будет искать его у других. Чую, без макросов тут не обойдётся...
> В таком случае как объявить m_pInst? С __declspec(dllimport)? Без этого каждая dll будет искать экземпляр у себя, а с этим dll с экземпляром будет искать его у других. Чую, без макросов тут не обойдётся...
Да, без макросов тут никуда
Posted via RSDN NNTP Server 1.9 alpha
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
>> В таком случае как объявить m_pInst? С __declspec(dllimport)? Без этого каждая dll будет искать экземпляр у себя, а с этим dll с экземпляром будет искать его у других. Чую, без макросов тут не обойдётся...
ПК>Да, без макросов тут никуда
В пределах одного модуля линкер разберётся, которую из инстанций метода grabli() оставить, и соответственно, single1_. А вот за пределами модуля... оппля.
Причём, заметьте — никаких шаблонов, просто статическая переменная в инлайновой функции.
О>Это объявление сейчас в заголовочном файле, который используется несколькими DLL. Соответственно, в каждой DLL создаётся по одному экземепляру.
Как это сделано в ACE:
#define ACE_EXPORT_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) template class __declspec (dllexport) SINGLETON_TYPE<CLASS, LOCK>;
#define ACE_IMPORT_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) extern template class SINGLETON_TYPE <CLASS, LOCK>;
При сборке самого dll (с реализацией шаблона) по ifdef'ам подставляете EXPORT, при включении заголовка в другой модуль — IMPORT.
...Спасибо одной известной фирме за такие извращения с библиотеками.
Кстати, есть такой термин даже — "dll hell".
О>Это объявление сейчас в заголовочном файле, который используется несколькими DLL. О>Соответственно, в каждой DLL создаётся по одному экземепляру.
Если делаем DLL, значит работаем под виндами, значит можно не погнушаться использованием mapped file. Хранить в нём разделяемые переменные ваших dll.
И вопрос. Я часто именно так и делаю. Найдутся ли какие-либо противопоказания у ALL?