DLL, RAII для интерфеса

Речь пойдёт, само собой, о неявно подключаемой dll для хранения классов. Решил пойти в сторону интерфейсов и фабрик классов, тут вроде всё просто, абстрактный класс с нужными методами и статик метод "Create()" в роли фабрики. Работаем с экземплярами классов через указатели, что не может радовать, ведь, создавая статик либу, я от этого пытался уйти, экземпляры некоторых классов привычно использовать по значению (константные ссылки и семантика перемещения мне в помощь). И вот задумал я засунуть интерфейсы в умные указатели, однако, за неимением явных конструкторов у первых, затея провалилась. Тогда я написал простенький RAII класс для конкретного интерфейса, хранящий указатель на экземпляр, в конструкторе вызываем функцию-фабрику (можно передавать как параметр шаблона), в деструкторе статик метод "Release(IMyClass*)", ну и оператор "->" для доступа к методам. Потестил, работает. Минус в, том что логика этого RAII класса должна быть в Header'е, хотя этого не избежать и потому, что этот должен быть шаблонный класс, ещё получается большая вложенность ресурсов, но тут можно заинлайнить методы RAII класса.
В общем имеет ли смысл использовать такой подход? Есть ли другие подходы? Всё-таки не вариант пользоваться голыми указателями, хоть new и delete явно больше не используются, на их место пришли "Create()" и "Release()".

0

не понятно что значит следующее:
пробовали ли юзать фичу кастомных делитеров для стандартных смартпоинтеров?

1

Сообщение от Perfilov не понятно что значит следующее:

На сколько мне известно, конструктор смартпоинта (например shared_ptr<IMyClass>) захочет вызвать конструктор IMyClass(), что ничего не даст.

Сообщение от Perfilov пробовали ли юзать фичу кастомных делитеров для стандартных смартпоинтеров?

Слабо я, видать, знаком со смартпоинтами... Наверняка ему и функцию-фабрику можно передать

0

Сообщение от Operok захочет вызвать конструктор IMyClass()

Создание объекта не на его совести. Так что не захочет.

Сообщение от Operok В общем имеет ли смысл использовать такой подход?

Недавно только демонстрировал. std::unique_ptr - это и есть один из стандартных смартпойнтеров. Указание кастомного делитера - присутсвует.

1

Многое прояснилось. Смартпоинты решил не засовывать в dll (в хедер), разбираться с этим надо уже в программе-клиенте. Более того, решил смотреть сразу в сторону COM.
Позвольте, задам здесь такой вопрос по использованию типа VARIANT. Работая с некоторыми компонентами (Excel.Application, например), методы возвращали этот тип данных, из которго я уже вытаскивал либо другой интерфейс, либо, например BSTR. Как подобное реализуется при создании своего компонента? "Руками" собирать "VARIANT" или возвращаем нужный нам тип (а клиент уже будет работать с вариантом)?

0