В последнее время я изучал создание DLL с использованием C ++ и случайно наткнулся на обсуждение «Абстрактные базовые классы против идиомы Pimpl», когда речь заходит о совместимости ABI.Я довольно новичок в работе с DLL, поэтому, пожалуйста, будьте терпеливы, если я неправильно понял термин / концепцию.Вот моя история:
Я читал в этой статье здесь на CodeProject.com , где автор заявляет, что использование абстрактного интерфейса - это путь.
Подводя итог: у вас есть абстрактный базовый класс class IFoo, фабричный метод extern "C" __declspec(dllexport/dllimport) IFoo* createFoo(); и фактическая реализация class FooImpl интерфейса IFoo, который фактически создается и возвращается createFoo().
Пока все хорошо.
Теперь я обнаружил, что некоторые люди утверждают, что только Pimpl-Idiom может сохранить совместимость с ABI ( В чем смысл шаблона PImpl, хотя мы можем использовать интерфейс для той же цели в C ++? , идиома Pimpl vs. Чистый интерфейс виртуального класса ), и я немного растерялся:
Как я понимаю, pimpl: у вас есть class Bar с указателем на class BarImpl, который содержит все детали реализации.
Мои вопросы:
Если я изменю только внутреннюю работу в обоих случаях (измените либо * 1032)* или class BarImpl) АБИ кода "Facing пользователь "в обоих случаях не меняет или делает это?
С другой стороны, оба подхода явно нарушают совместимость ABI, если я внесу изменения в class Foo или class Bar,право ?
В случае, если мои предположения о совместимости ABI с использованием абстрактных базовых классов неверны.Нужно ли использовать смесь абстрактных базовых классов в DLL, чтобы действительно поддерживать ABI-совместимость, если я только выполняю изменения во внутреннем коде библиотек?
Iнадеюсь, я смогу четко сформулировать, что для меня непонятно;)
РЕДАКТИРОВАТЬ: Под "изменением внутренних компонентов" я также имею в виду добавление / удаление членов / методов в классах реализации FooImpl и BarImpl.