В С++ нарушает ли ABI переопределение существующей виртуальной функции?

Это может быть.

Вы ошибаетесь насчет смещения. Смещение в vtable уже определено. Что произойдет, так это то, что конструктор класса Derived заменит указатель функции по этому смещению переопределением Derived (путем переключения v-указателя в классе на новую v-таблицу). Так что, как правило, он совместим с ABI.

Однако может возникнуть проблема из-за оптимизации и особенно девиртуализации вызовов функций.

Обычно, когда вы вызываете виртуальную функцию, компилятор вводит поиск в vtable через vpointer. Однако, если он может вывести (статически), каков точный тип объекта, он также может определить точную функцию для вызова и сократить виртуальный поиск.

Пример:

struct Base {
  virtual void foo();
  virtual void bar();
};

struct Derived: Base {
  virtual void foo();
};

int main(int argc, char* argv[]) {
  Derived d;
  d.foo(); // It is necessarily Derived::foo
  d.bar(); // It is necessarily Base::bar
}

И в этом случае... простое связывание с вашей новой библиотекой не поднимет Derived::bar.

Это не похоже на то, на что можно было бы особенно полагаться в целом - как вы сказали, C++ ABI довольно сложен (даже вплоть до параметров компилятора).

Тем не менее, я думаю, вы могли бы использовать g++ -fdump-class-hierarchy до и после внесения изменений, чтобы увидеть, изменяются ли структура родительских или дочерних виртуальных таблиц. Если они этого не сделают, вероятно, «довольно» безопасно предположить, что вы не нарушили ABI.

Да, в некоторых случаях добавление новой реализации виртуальной функции будет изменять структуру таблицы виртуальных функций. Это тот случай, если вы повторно реализуете виртуальную функцию из базы, которая не является первым базовым классом (множественное наследование):

// V1
struct A { virtual void f(); };
struct B { virtual void g(); };
struct C : A, B { virtual void h(); }; //does not reimplement f or g;

// V2
struct C : A, B {
    virtual void h();
    virtual void g();  //added reimplementation of g()
};

Это изменяет макет vtable C, добавляя запись для g() (спасибо «Gof» за то, что он обратил мое внимание на это в первую очередь, как комментарий в http://marcmutz.wordpress.com/2010)./07/25/bcsc-gotcha-reimplementing-a-virtual-function/).

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

MyClass * c = new MyClass;
c->myVirtualFunction(); // not actually virtual at runtime

или создал его в стеке:

MyClass c;
c.myVirtualFunction(); // not actually virtual at runtime

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

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

Моя интуиция такова, что он должен изменить смещение в vtbl без фактического изменения размера таблицы.

Что ж, ваша интуиция явно неверна:

• либо в vtable есть новая запись для переопределения, все последующие записи перемещаются, и таблица растет,
• или нет новой записи, и представление vtable не меняется.

Какой из них верный, зависит от многих факторов.

В любом случае: не рассчитывайте на это.

Внимание: см. В C++ нарушает ли ABI переопределение существующей виртуальной функции? в случае, когда эта логика неверна;

На мой взгляд, предложение Марка использовать g++ -fdump-class-hierarchy было бы здесь победителем сразу после проведения надлежащих регрессионных тестов

Переопределение не должно изменять макет виртуальной таблицы[1]. Сами записи vtable будут в сегменте данных библиотеки, ИМХО, поэтому изменение его не должно вызывать проблем.

Конечно, приложения необходимо повторно связать, иначе существует потенциал поломки, если потребитель использовал прямую ссылку на &Derived::overriddenMethod; Я не уверен, было бы разрешено компилятору разрешить это для &Base::overriddenMethod вообще, но лучше перестраховаться, чем потом сожалеть.

[1] разъяснение: это предполагает, что метод был виртуальным с самого начала!