Как лучше запрограммировать наследование в Си?

Question

[rhaport]

Доброго времени суток.

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

Возникла надобность расширить структуру для опрелённой функциональности. Но саму структуру менять не хочется, да и не надо, так как в других местах эта функциональность не нужна. Что делать? Есть две идеи:

1) добавить в структуру struct Base поле указатель на void, где жаждущие могут сложить всё дополнительное
2) Создать структуру типа

struct MyCustomStruct
{
    struct Base base;
    t_whatever whatever;
    .... 
}

Соблюдая выравнивание, указатель на struct MyCustomStruct будет также указывать на Base. Таким образом его можно будет передавать в коллбэк функции и вроде как счастье.

Покритикуйте, пожалуйста, оба подхода и если есть другая идея, поделитесь ими :)

Answer 1

[VekaVeka]

Это решено уже лет 30 назад.

Посмотрите WinAPI.

Comments

[rhaport]

Я думаю, что 99% всех текущих задач так или иначе решены в 60-70 годах. Тем не менее можно по подробнее? Я с WinAPI никогда не работал. Можно ссылку на статью? Или может пару ключевых слов? WinAPI очень обширная штука. Это как человеку, не знающему OOO, но желающему запрограммировать список на C++, посоветовать посмотреть STL...

[AtomKrieg]

rhaport: человек, который хочет запрограммировать список - делает это в порядке обучения и должен сделать это самостоятельно. Человек, которому нужно решать реальные задачи идет на тостер и получает подсказку.

[VekaVeka]

rhaport: В почти любых структурах WinAPI имеется механизм расширения.
Идея в том что в начале мы указываем размер (и версию/тип структуры).
В реальности мы можем ссылаться как на
{
int Size
int A
}

так и на

{
int Size
int A
int B
}

А Size используется чтобы не выйти за границы, в случае использования короткой версии структуры.

[rhaport]

VekaVeka: спасибо за экскурс. Идея ясна. Эта идея развивается подробно в книге, которую можно найти по ссылке, приведённой Ivan Sokolov в его ответе. В моём приложении нет динамического выделения памяти из кучи, все объекты статические. И я не собираюсь проверять в рантайме длину объекта, так как это оверхэд по времени. К тому же длинной иерархии не предвидится и в принципе в системе мало памяти, поэтому любой оверхэд не желателен. Поэтому вариант 2) наверное приемлем.
Вариант 1) хорош наверное только тем, что если юзер возьмёт указатель на объект базового класса и попробует дереференциировать указатель на void, который NULL, то система сразу выдаст исключение. В варианте 2) кастинг к кастомному классу указателя на базовый может пройти незамеченным сразу. Система лажанёт где-то позже и будет сложнее понять почему. Надо подумать какова вероятность, что такое будет происходить.
Недостаток 1) это то что на указатель на void всегда тратятся 4 байта даже если используется только базовая структура в чистом виде. Кроме того юзер всегда неявно должен знать, что прячется под указателем на void.

[VekaVeka]

rhaport:

В моём приложении нет динамического выделения памяти из кучи, все объекты статические. И я не собираюсь проверять в рантайме длину объекта, так как это оверхэд по времени. К тому же длинной иерархии не предвидится и в принципе в системе мало памяти, поэтому любой оверхэд не желателен.

Проверка размеров - это считанные такты, число которых - миллиарды в секунду.

В принципе в системе мало памяти и статически распределено - вам все равно понадобятся проверки - а чем фактически является та или иная структура.

[rhaport]

VekaVeka: согласен, что это недолго, но тем не менее это дополнительные такты в системе реального времени и к тому же дополнительный код, который делает дополнительную проверку, занимает место в IRAM. Однако надо взвесить и подумать. Спасибо за направление.

[VekaVeka]

rhaport: система реального времени - это не "быстро",
а "гарантировано по времени".

То есть "запрос займет не более чем столько то времени. всегда. гарантировано."

[rhaport]

VekaVeka: да "гарантированно по времени", но время жёстко ограниченно требованиями. Поэтому надо не упускать и перформанс из виду.

[VekaVeka]

rhaport: это рассчитывается.

а не просто экономится на всем подряд - ведь на кое каких вещах, вроде отдельных тактов на проверку - экономить и не нужно.

[InoMono]

rhaport,

В моём приложении нет динамического выделения памяти из кучи, все объекты статические. И я не собираюсь проверять в рантайме длину объекта, так как это оверхэд по времени. К тому же длинной иерархии не предвидится и в принципе в системе мало памяти, поэтому любой оверхэд не желателен.

Если памяти мало, то как раз неплохо было бы и использовать разные версии структур.
Когда полные длинные, а когда укороченные - та самая экономия.

Answer 2

[Сергей Протько]

вместо наследования имеет смысл применить макросы, ибо "наследование типов" для вашей задачи насколько я понял не нужно.

Comments

[rhaport]

в моей задаче базовый класс - это конечный автомат, а коллбэки - это обработчики смены состояния автомата. Я вижу смысл в наследовании, чтобы уметь изменять/читать дополнительные параметры кастомного автомата в обработчиках, не меняя базового принципа и строения автомата. Можно пример, как макросы могут помочь?

[Сергей Протько]

rhaport: вы хотите полиморфизм подтипов или наследование? вы уж определитесь.

[rhaport]

разве это взаимоисключающие вещи? Почему нужно сделать выбор? В общем, я хочу наследования. Но это не запрещает мне объявлять в базовом классе указатели на функции, которые будут определены в кастомном объекте. Конкретно по вопросу мне интересно как эффективно организовать наследование. Если наличие полиморфизма, будет остро влиять на вариант реализации наследования, то конечно можно обсудить.

[Сергей Протько]

rhaport: наследование приследует единственную цель - устранение дублирования. С этим легко справляются макросы.

В целом же ваш второй вариант справляется с задачей, в чем ваше сомнение?

[rhaport]

В целом да. Но хотел услышать другие мнения и варианты. Можно по подробнее про макросы. Как именно можно их здесь использовать?