Как стать автором
Обновить

Комментарии 24

Осталось таблицу виртуальных методов объявить как static, чтобы был только один экземпляр, да поставить на неё указатель в структуре и получится обычный vtable.
Можно, но я хотел избавиться от промежуточных сущностей.
Но увеличился расход памяти т.к. таблица хранится в каждом экземпляре класса.
Да, эта проблема есть. Однако в моем случае в конструкторе можно в зависимости от параметров назначать различные функции. С vtable так не получится.
А во-вторых, расход памяти увеличится, если больше 1-го метода в интерфейсе. В простейших случаях можно и одним методом на интерфейс обойтись.
К месту ли ваши модные мемы, а?
Возможно, не к месту. Но без них вообще не за что зацепиться в статье.
В серьезной технической статье они немного глуповато выглядят, ИМХО.
Они вообще глуповато выглядят, ИМХО.
Убрал мемы. Не знал, что они послужат поводом сливать карму.
Посмотрите, как написан Gtk.
Я скопировал их велосипед? :)
Gtk большой, на что именно советуете посмотреть?
В какой-то мере. :)
Точнее это GLib, см. GObject/GObjectClass, bit.ly/TmFYPh
Ну, ясное дело, что умные люди давно эту схему придумали и используют.
Но, насколько я понял, все «объекты» в GTK+ наследуют один и тот же интерфейс: GObjectClass. Я же пытался реализовать множественное наследование. Возможно, и такое у разработчиков уже есть.
Нет, один объект может наследоваться от другого
А множественное наследование есть?
Вроде нет. Попробовал сейчас в Vala, получил ошибку — «Classes cannot have multiple base classes».
Зачит, от моего велосипеда хоть какая-то польза. :)
О я так писал на первом курсе университета на паскале. Объекты мы еще не знали. Так вот я написал:
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).
Добавил книгу в раздел литературы.
Добавил ссылку в раздел литературы.
Спасибо за статью! Что-то начали на хабре снова появляться серьёзные технические вещи, что не может не радовать =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории