LINUX.ORG.RU

Посоветуйте современную эмуляцию «классов» для С в эмбеды

 , ,


3

3

https://github.com/lvgl/lvgl/issues/1919

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

Если кто в курсе, на чем нынче модно ООП для С изображать, дайте знать. Надо для эмбедов:

  • много оперативки жрать нельзя.
  • много флеша жрать не желательно.

По фичам критично только наследование методов/данных и virtual. Можно забить болт на private, эксепшены, множественое наследование и т.п.

Ответ типа «лучше ooc toolkit до сих пор ничего не придумали» - тоже устроит.

★★★★★
Ответ на: комментарий от PPP328

Ты не совсем понял вопрос. Экземпляр класса хранит указатель (object->class_ref) на дескриптор класса, где мы можем извлекать инфу о методах, наследовании и т.п. Грубо говоря - еще одна структура сбоку лежит, единая для всех классов (как ты и сказал).

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

Вопрос был, нафига авторы библиотеки так делали :). Или возможно я что-то не так понял.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

Вопрос был, нафига авторы библиотеки так делали :).

Адекватные люди таких библиотек вообще делать не будут. Ничего не мешает хранить указатели на виртуальные методы напрямую в дескрипторе класса. В C++ именно так и сделано. В C++ Itanium ABI (GCC, clang) дескриптор класса находится по смещению 0 и содержит указатели на виртуальные методы а также на type_info.

X512 ★★★★★
()
Ответ на: комментарий от X512

Ну может там какие-то траблы с тем, чтобы трансформировать human-friendly описание класса в конечный результат (где указатели на функции уже выставлены с учетом наследования).

Я поэтому и спрашиваю, могли быть причины или нет. Может, например, автор хотел явно отделить виртуальные методы от остальных. Фик знает, в чужую голову же не залезешь.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

ссылка на дескриптор класса нужна скорее всего для какого-то подобия rtti, ссылка на класс скорее всего содержит ссылку на дескриптор класса предка, чтобы в рантайме проверить наследуется ли данный класс от другого. ну и дескриптор несет еще какую-то инфу. а vmt содержит виртуальные методы доступные классу.

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

короче это не принципиально, вопрос в том, что они в свое ооп заложили там.

alysnix ★★★
()
Ответ на: комментарий от alysnix

ссылка на класс скорее всего содержит ссылку на дескриптор класса предка

В C++ ABI наоборот указатель на дескриптор типа находится в vtable потому что к vtable обычно требуется более быстрый доступ чем к информации о типе. Видел реализацию ООП где в дескрипторе типа также хранятся указатели на виртуальные методы по отрицательным смещениям.

X512 ★★★★★
()
Ответ на: комментарий от X512

В C++ ABI наоборот указатель на дескриптор типа находится в vtable потому что к vtable обычно требуется более быстрый доступ чем к информации о типе

это по взрослому.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

rtti надо обязательно, а вот всякую изоляцию внутри классов - нет. Если все будет а ля «virtual» + «public» - сойдет.

Тогда остается вопрос, как покрасивше организовать декларацию данных и методов для классов.

Vit ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.