Нижеизложенное является не более, чем соображениями из серии: "я бы делал примерно так".
И ни в коем случае не фиксируют "некие баги" - их просто нет. А "соображения" - не меняют исходной функциональности.
1) В определении "класса" и vmt я бы убрал один уровень вложенности. Т.е. объект имеет указатель сразу на vmt, а уже именно в этой таблице: первым полем - адрес vmt предка, вторым - пускай будет адрес имени, далее - адреса виртуальных методов (кстати, первым методом обычно делают деструктор)
2) Настораживают два "параллельных" массива в layout_t: _.children и sizings
Мне кажется, вместо sizings типа ptr_array_t надо завести просто одно поле sizing типа dword внутри, может даже и widget_t - и всего делов-то
3) Про то, что "детишки" организованы в виде массива.
Мне кажется что удобнее делать их было в виде списка. Ну или как двунаправленный список. В букварях вроде рисуют сводные таблицы возможностей для эдаких (массивы, списки, двунаправленные, ассоциативные, и т.п.) структур данных.
Вроде бы: сверх быстрый доступ именно по индексу - не очень-то и нужен, перечисление - и в списках идет нормально, удаление и вставка элемента - могут и для произвольного элемента понадобиться, и тут списки как раз и выигрывают...
Получится, что некий контрол должен иметь два указателя - на своего "соседа", и на вход в цепочку "детишек". Ну или по "паре ссылок", для случая двунаправленных списков.
Мне кажется, это рациональнее, чем динамический объект, на который указует ptr_array_t
4) Не очень понятно применение widget_is_kind_of, если по большому счету-то. Я бы вообще наплевал на проверку классов. как следствие - могла бы оказаться ненужной и вся система RTTI.
Ну нет у контрола детишек, вот и нет перечисления.
Но, возможно, это уже следствие в "разности концепций" - надо чтобы класс widget_t содержал в vmt метод arrange_widgets. Т.е., все "классовое различие" начинает как бы и пропадать...
Не, ну я свято верю в то, что лучшее средство от перхоти - гильотина
5) Ну и совсем не принципиальное замечание, больше стилистического характера.
Вроде бы fasm позволяет наследовать структуры. Примерно так:
Code: Select all
struct layout_t container_t
sizings ptr_array_t
sizing dd ? ; кто такой, почему не знаю...
spacing dd ?
ends
тогда не пришлось бы приводить один указатель к разным классам
Code: Select all
mov esi, [ebx + layout_t.children] ; было container_t
mov edi, [ebx + layout_t.sizings]
Приведение к разным - напрягает. Особенно по-началу, когда иерархия классов в голове еще не твердо сидит.
=============================================================================
ЗЫ: если написал не очень понятно (немного наспех), ТО: на любой Ваш вопрос - любой наш ответ
