RAII для инициализации в DLLМожно ли осуществлять инициализацию объектов бизнес логики через RAII, т.е. тупо объявляя статические объекты в cpp-файлах в dll-ке, которая линкуется динамически к программе?


Да.

RAII для инициализации в DLLДопустим есть программа, в .h-файле которой определена глобальная переменная.

в .h-файле не может быть определена глобальная переменная.
Она там может быть объявлена.
Если она там определена, это -- ошибка. Это -- один шаг до нарушения ODR.
Такое может работать только если этот заголовок включается не более чем в один исходный модуль.

RAII для инициализации в DLL И эта программа во время исполнения динамически линкует к себе dll-ку. В этой dll-ке инициализация происходит в конструкторе глобального статического объекта, который обращается к глобальному объекту в самой программе (объект глобально объявлен в .h-файле, который используется и в программе и в dll-ке).
Насколько такая схема логична и переносима в общем случае?

Если ты собираеш с этим заголовком и .exe, и .dll, то твоя переменная (скорее всего) просто тупо будет объявлена и определена 2 раза, один раз -- в .exe, второй - в .dll. и .dll будет использовать свою переменную. Т.е. это будут две разные голобальные переменные, называемые одинаково на уровне исходного кода, но имеющие разные адреса на уровне машинного.

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

Как ты это всё делаешь -- надо вообще-то код смотреть.

White OwlRAII для инициализации в DLLЯ предлагаю не передавать параметром этот объект в функцию init, а просто в самой init обращаться к нему, как к глобальному объекту, объявленному в программе.

Это тоже возможно, но для этого надо чтобы главная программа регестрировалась в OS каким-то образом. Тогда модуль сможет "искать прогамму" к которой ему надо подключаться. Вараинты: сделать именованый pipe, сервис, или даже открыть TCP сокет.


Что-то ты, Большой Мудрый Белый Сов заработался. Или наоборот, заотдыхался.
Это один процесс, у них одна память, зачем им средства межпроцессного взаимодействия использовать?

RAII для инициализации в DLLТ.е. этот объект либо передавать параметром в функцию инициализации, либо через "именованый pipe, сервис, или даже открыть TCP сокет." или экспортировать из .exe определенный в .cpp программы и объявленный в общем .h-файле?


Можно ещё на диск записать, зазиповать, потом в модуле (.dll) раззиповать, десериализовать в память, сделать с ним всё, что надо,
потом опять записать на диск, зазиповать, и потом главная программа опять этот объект раскрутит в обратном порядке.

Только нахрена, если этот объект лежит в памяти, общей для библиотеки и программы ?

Хотя просто передавая указатель на этот объект в функции инициализации плагина, ты сможешь избежать изрядной доли гемора на свою задницу.

А вот если фунции такой не планируется, и/или хочется инициализировать плагины автоматом, то -- да, надо морочиться с export/import.

Dimitry SibiryakovWhite OwlУ уже работающей программы "экспортированные" функции и переменные
превращаются в адреса в памяти и как "точки экспорта" более не доступны.

Однако GetProcAddress() вроде бы как работает...


Я тоже как-то не сталкивался с этим. Из .exe мы линковали данные в загружаемые динамически .dll.
Хотя возможно я забыл, и это были не данные, а функции. Но вообще странно, GetProcAddress()-у то
по барабану, адрес -- и адрес, а функция это или переменная -- дело программы.

OoCckosh the best> Разделяемая библиотека не обязaна инициализировать статические обьекты.
???
Исполнение стартовой функции при загрузке разделяемой библиотеки - это исключительно для вызова С++ конструкторов. С другой стороны это за пределами С++ стандарта. Да PE и ELF форматы это делают. Но одно дело "делать" и совсем другое "обязан сделать".

Что за пределами стандарта, вызов конструкторов статических объектов ?
:-)

Вот создателям библиотек и приходится реализовывать эти требования стандарта.
Разделяемые библиотеки -- за пределами стандарта, но если они хотят содержать код на С++, то им
приходится поддерживать требования этого языка.