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

Как это не важно?
У Вас какой режим оптимизации включен, по размеру или по времени?
А если по размеру? Вот он вам такой код и генерит.
Поставте О3, и включите опцию оптимизации по времени.
Возможно, и не понадобится вся эта канитель, что тут развели

Добрый день.

Тип оптимизации по времени с повторным использованием одинакового куска кода (сворачиват повторения в процедуры).

А канитель эта по любому нужна

А что мешает просто красиво задать массив, - с одной функцией в одной строке и коментарием в конце строки, который будет указывать номер текущей позиции:


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

Я делал так раньше, неудобно - слишком много переименовывать.
Как раз на днях заказчик попросил поменять последовательность функций в менюшке. Одно дело перетасовать имена функций, другое дело отслеживать физические индексы. Не говоря уже о том, чтобы добавить раздел в меню.

Приветствую!




Я похожее делал для определения набора переменных в flash. Структуры задающие переменные (в разных модулях) при определении назначались в именованный сегмент памяти. При линковке все что в этом сегменте было определено складывалось в одну большую таблицу начало и размер которой известны. Естественно положить таким образом указатель в определенную позицию в таблице нельзя.

Успехов! Rob/

Если смотреть в контексте использования для какого-то протокола из-вне (модбас / мэк101 / 104 и т.п. много всяких у кого 256 функций), где функции (большинство их) жестко определены стандартом. То существенно менять ничего не придется, никто функции протокола менять не будет. Функции могут только неспешно добавляться как и отметил автор ветки.

А для меню думаю куда удобнее и нагляднее хранить описатель пункта меню, который включает что-то типа
- ссылку на верхнее меню (parent)
- ссылку на субменю (если есть)
- имя пункта (то что выводится на экран)
- параметры шрифта
- ссылку на функцию-аутентификатор (не все же можно выполнять сразу, кое-что может требовать особого подтверждения)
- ну и ссылку на действие. (специально поставил последним)

вместо таблицы голых функций.

С этим можно побороться с помощью паттерна Singleton.



Использование:


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

А я не исключаю включение в массив дополнительно к указателям на функции вспомогательной информации. Но для меня реализация всего интерфейса пользователя как единого автомата состояний получается гораздо прозрачнее и удобнее. Законченный фрагмент исходника должен поместиться на экране. Меньше ссылок, больше прямых действий. От "глобальной" индесации массива функций [state][event] я сделал шаг назад, к function[state].
Впрочем, я уже о своем, наболевшем - не перебдеть в структурировании

А чем нам поможет замена глобального объекта на глобальный статический? В плане руления порядком вызова конструкторов? То есть, чем это отличается от простого объявления
?
Имхо, без динамического создания объектов singleton совершенно бесполезен.

Вот зрасьте! В этом же вся фишка синглтона. Когда какой-то объект нуждается в объекте TSlon, то он создает (использует) ссылку, возвращаемую функцией Instance() шаблона singleton. А ссылка эта ссылается на статический объект, создаваемый внутри фукнции-члена Instance(). Таким образом, получается следующая схема: при первом вызове Instance() будет создан и проинициализирован статический объект требуемого типа (в нашем примере TSlon), все последующие вызовы будут возвращать ссылку на уже существующий объект. И не важно, кто первый дернул Instance(), думать об этом не надо. В этом и избавление от зависимости от порядка вызова конструкторов.


Еще как полезен: объект создается как статический внутри статической же функции-члена Instance(). И живет там все время, пока программа работает. Т.е. по сути как обынчый глобальный объект, но спрятанный внутри функции и предоставляющий доступ по ссылке (что синтаксически ровно как доступ к обычному объекту). Нету тут ни работы с кучей, ни выделения памяти на рантайме. Выделение памяти и инициализация производятся комилятором на основе правил языка в части статических объектов внутри функций (которые есть даже в голом С).

Упс. Я был уверен, что разница между статическим и глобальным объектом только в области видимости.
А ты хочешь сказать, что для статических объектов конструкторы вызываются не в списке глобальных конструкторов, а при первом вызове функции, в которой он содержится? Если так, то это супер! Надо проверить

Статический объект должен быть гарантировано проинициализирован до его использования. А где это делается - отдано на откуп реализации. Например:

Реализация может быть разной. Самое простое - сунуть а в секцию, где помещаются глобальные переменные, и проинициализировать вместе с ними (IAR, помнится, так и делает) - разница тут будет только в области видимости. А можно тут вставить код, проверяющий первый вход в функцию, и вызывать инициализатор (это тот самый оверхед, про который я говорил, и который незначителен по сравнению с вызовом конструктора). Как делается реально в том или ином случае - это в ведении реализации (в случае с вызовом конструктора объекта пользовательского типа скорее всего делается по второму варианту). Главное, что поведение четко стандартизовано и это можно безопасно использовать.

Попробовал, получилось. Но далеко не сразу. Простая замена глобального объекта

на ссылку:

Не прокатила. Потому что теперь вместо глобального объекта uart1 у нас получилась глобальная же ссылка Порядок инициализации которой (на этот раз при помощи хитрого синглетона!) по прежнему не определён.
Пришлось везде, где используется uart1, заводить локальные переменные-ссылки

и использовать их. Вот тогда всё заработало должным образом
Что касаемо накладных расходов, то они достаточно приличные:

(Всё это gcc на stm32)

Я думаю, что для некоторых применений это хорошее решение, по крайней мере я намерен его применять.
(Или всё же new? )

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


Для new надо свой быстрый и не подверженный фрагментации менеджер памяти сделать. Если только для вышеописанных целей, то это будет еще больше накладных. А вообще такой мененжер памяти местами очень полезен. Надо будет сделать, как руки дойдут.