Смешение менеджера памяти DLL

Я написал приложение, которое позволяет людям добавлять плагины для расширения функциональности. Такие плагины развертываются в виде DLL-файлов, которые фреймворк собирает во время выполнения. Каждый плагин имеет функцию фабрики, которая вызывается несколько раз в течение жизненного цикла приложения для создания объектов. До сих пор для решения проблемы владения этими объектами я использовал простой подсчет общего указателя на возвращаемые объекты, чтобы они уничтожались при удалении последней ссылки.

Однако это имеет тенденцию вызывать сбои в Windows, поскольку не исключено, что объект будет новым в DLL плагина, но позднее (из-за вызова deref () для общего указателя) будет удален в основном приложении - и AFAIK, это смешение malloc / free - нет-нет в Windows.

Мое текущее решение этой проблемы - позволить deref () не вызывать «удалить это»; непосредственно, а не «release ();» функция, которая должна быть реализована плагинами и вызывает "удалить это". Тем не менее, довольно неприятно, что каждый плагин должен реализовывать эту тривиальную функцию - до сих пор я работал над этим, предоставляя удобство, которое должны использовать авторы макро-плагинов. У кого-нибудь есть альтернативные идеи?

Пока что мой подход заключается в том, что все объекты, добавленные плагинами, размещаются в плагинах, а также освобождаются там - конечно, альтернативой может быть предоставление всей памяти в основном приложении (путем предоставления указателя на функцию, похожую на malloc). к плагинам, которые они могут затем вызывать по мере необходимости) и выпускаются там же. Проблема в том, что это не так удобно для авторов плагинов, я думаю.

Я был бы заинтересован в любых других взглядах на этот вопрос.

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

Ответы на вопрос(3)

Ваш ответ на вопрос