Как разработать API C++ для двоичной совместимой расширяемости

В базе знаний KDE есть интересная статья, которая описывает, что можно и чего нельзя делать при написании библиотеки для обеспечения двоичной совместимости: Политики / Проблемы двоичной совместимости с C ++

Совместимость двоичных файлов C ++ обычно затруднена даже без наследования. Посмотрите, например, на GCC. Я не уверен, сколько критических изменений ABI произошло за последние 10 лет. Затем MSVC имеет другой набор соглашений, поэтому привязка к нему с GCC и наоборот невозможна ... Если вы сравните это с миром C, взаимодействие компилятора там будет немного лучше.

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

Я думаю, вы неправильно понимаете проблему создания подклассов .

Вот ваш сутенер:

// .h
class Derived
{
public:
  virtual void test1();
  virtual void test2();
private;
  Impl* m_impl;
};

// .cpp
struct Impl: public Base
{
  virtual void test1(); // override Base::test1()
  virtual void test2(); // override Base::test2()

  // data members
};

void Derived::test1() { m_impl->test1(); }
void Derived::test2() { m_impl->test2(); }

Видите? Нет проблем с переопределением виртуальных методов Base , вам просто нужно заново объявить их virtual в Derived , чтобы те, которые были получены из Derived, знали, что они могут переписать их тоже (только если вы того пожелаете, что, кстати, является отличным способом предоставить финал для тех, кому его не хватает), и вы все еще можете переопределить его для себя в Impl , который может даже вызвать версию Base .

Там нет проблем с Pimpl .

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