forgoty, согласен с Ariox41 . Ситуация может измениться при использовании ключей оптимизации. Попробуйте -О3. Также при увеличении сложности программы контент стека может быть другим.
Никто не заставляет терять навыки. Закончив аспирантуру в 27-28 получите билет в жизнь. Даже не представляете какие шансы открываются. Но это не просто
VekaVeka: согласен, что это недолго, но тем не менее это дополнительные такты в системе реального времени и к тому же дополнительный код, который делает дополнительную проверку, занимает место в IRAM. Однако надо взвесить и подумать. Спасибо за направление.
разве это взаимоисключающие вещи? Почему нужно сделать выбор? В общем, я хочу наследования. Но это не запрещает мне объявлять в базовом классе указатели на функции, которые будут определены в кастомном объекте. Конкретно по вопросу мне интересно как эффективно организовать наследование. Если наличие полиморфизма, будет остро влиять на вариант реализации наследования, то конечно можно обсудить.
VekaVeka: спасибо за экскурс. Идея ясна. Эта идея развивается подробно в книге, которую можно найти по ссылке, приведённой Ivan Sokolov в его ответе. В моём приложении нет динамического выделения памяти из кучи, все объекты статические. И я не собираюсь проверять в рантайме длину объекта, так как это оверхэд по времени. К тому же длинной иерархии не предвидится и в принципе в системе мало памяти, поэтому любой оверхэд не желателен. Поэтому вариант 2) наверное приемлем.
Вариант 1) хорош наверное только тем, что если юзер возьмёт указатель на объект базового класса и попробует дереференциировать указатель на void, который NULL, то система сразу выдаст исключение. В варианте 2) кастинг к кастомному классу указателя на базовый может пройти незамеченным сразу. Система лажанёт где-то позже и будет сложнее понять почему. Надо подумать какова вероятность, что такое будет происходить.
Недостаток 1) это то что на указатель на void всегда тратятся 4 байта даже если используется только базовая структура в чистом виде. Кроме того юзер всегда неявно должен знать, что прячется под указателем на void.
в моей задаче базовый класс - это конечный автомат, а коллбэки - это обработчики смены состояния автомата. Я вижу смысл в наследовании, чтобы уметь изменять/читать дополнительные параметры кастомного автомата в обработчиках, не меняя базового принципа и строения автомата. Можно пример, как макросы могут помочь?
Я думаю, что 99% всех текущих задач так или иначе решены в 60-70 годах. Тем не менее можно по подробнее? Я с WinAPI никогда не работал. Можно ссылку на статью? Или может пару ключевых слов? WinAPI очень обширная штука. Это как человеку, не знающему OOO, но желающему запрограммировать список на C++, посоветовать посмотреть STL...
Да, об этом тоже думал. Но количество файлов будет расти. Есть также опасность, что кто-нибудь начнёт добавлять C++ный код в include.hpp и это трудно будет отследить.
Ну как бы Air не подходит по Вашим требованиям, так как они максимум 13.3" емнип. Ну и разрешение там не HD. Мне например надо всегда видеть два открытых окна с кодом. С 1440x900 конечно жить можно, но 1920x1080 гораздо лучше.
