Осталось таблицу виртуальных методов объявить как static, чтобы был только один экземпляр, да поставить на неё указатель в структуре и получится обычный vtable.
Да, эта проблема есть. Однако в моем случае в конструкторе можно в зависимости от параметров назначать различные функции. С vtable так не получится.
А во-вторых, расход памяти увеличится, если больше 1-го метода в интерфейсе. В простейших случаях можно и одним методом на интерфейс обойтись.
Ну, ясное дело, что умные люди давно эту схему придумали и используют.
Но, насколько я понял, все «объекты» в GTK+ наследуют один и тот же интерфейс: GObjectClass. Я же пытался реализовать множественное наследование. Возможно, и такое у разработчиков уже есть.
О я так писал на первом курсе университета на паскале. Объекты мы еще не знали. Так вот я написал:
const length=10;
type
vofunc = function (self);
menu = record
items: array[0..length];
draw: vofunc;
end;
Где а потом добавлял метод и всегда первым параметром передавал саму структуру. у преподавателя глаза полезли на лоб.
Я применил подобный подход для драйверов GPIO в библиотеке для дисплеев на контроллере HD44780 (сорцы, статья с объяснением). Думаю, более-менее опытному разработчику на C этот подход рано или поздно придёт в голову даже даже без знания C++ и ООП, так как естественен для C. А в ядре Linux он используется весьма активно: читаем книгу «Идеальный код» (Beatiful Code), главу 16 — «Модель драйверов ядра Linux: преимущества совместной работы» за авторством Грега Кроа-Хартмэна (Greg Kroah-Hartman).
Добавляем немного виртуальности в C