Управление внешней памятью и COM

Question

Возникли проблемы с управлением памятью сторонней библиотеки. У меня есть исходный код, но он очень сложный (COM-материал), полный макросов и раздражающих аннотаций Microsoft и т. Д., И взаимодействует с другой библиотекой, источник которой мне не нужно загружать. Теперь некоторые быстрые среды выполнения отладки показали, что это утечка памяти и довольно сильно. Я широко использую самораспускающиеся указатели, такие как unique_ptr, и знаю, что я выпустил все, что создал. Это мой единственный способ попытаться очистить (и понять) источник?

Кроме того, безопасно ли назначать COM-объекты оператором new или они должны помещаться в кучу COM?

Answer 1

COM довольно независим от того, как вы распределяете свои собственные COM-объекты.Они создаются фабрикой классов, а ваши методы IUnknown :: AddRef и Release сохраняют счетчик ссылок.Использование оператора new в фабрике классов и delete this в Release - это нормально.

Вы должны быть осторожны с любыми указателями, которые вы возвращаете в своих методах интерфейса.Типичные объекты автоматизации, такие как BSTR и SAFEARRAY, действительно должны быть размещены в куче COM, чтобы клиентский код мог их освободить.Довольно сложно все испортить, API работает.

Клиентский код может быть ответственным за утечку, возиться с подсчетом ссылок - довольно стандартная ошибка COM.Обычно легко диагностировать, когда у вас есть доступ к реализациям AddRef / Release.Также настоятельно рекомендуется отладить это в Vista или Win7, у них есть гораздо лучший менеджер кучи, который не игнорирует попытки освободить память из неправильной кучи.эти утечки затем изолируют проблему с заголовком <crtdbg.h> и модульными тестами для проверки методов интерфейса.