Това е класически проблем при зареждане на DLL-и, когато се ползват един друг и трябва да се инициализират по подходящ начин преди това. В нета има множество примерни решения с класчета, аз съм ползвал такива преди много време, но може и сам да ги намериш. А и не е сложно да се напишат.
Иначе специално ГЦЦ имаш приоритети на конструкторите, ама това си е само ГЦЦ...



В Ц++ имаш всичко което го имаш и на чисто Ц++. Само дребни ГЦЦ-екстеншъни не се поддържат но това са незначителни неща. Така че каквото може да направиш на Ц може по същия начин да направиш и на Ц++. Обратното обаче не е вярно. Ц++ ти позволява оптимизации дето няма как да направиш на чисто Ц. Примерно една и съща функция веднъж да се вика run time веднъж compile time по преценка на компилатора. Наясно си предполагам до каква разлика в кода може да доведе това
А що се отнася до по-малко писане... ето ти пример:



В случая имаш списък от int-ве но може да е списък от каквото си пожелаеш. Забележи как се прави обхождане с range loop... много по-кратно и много по-чисто.
Другото, което не се вижда на пръв поглед е, че списъкът е само от константи. И доколкото се ползват само push методи компилаторът може да ги оптимизира напълно, т.е. няма да сложи код за изграждане на списък, а просто готов списък в секцията за константи. Може да отиде и още по-далеч ако гониш скорост - изобщо да няма абсолютно никакъв списък, а само викане на 5 последователни printf-a с предварително подготвени стрингове. Такива дълбоки оптимизации са почти немислими на чисто Ц

Миро, знам че може
Дай да не цапаме тука темата на Веско ... то спора Ц срещу Ц++ не е от вчера, едва ли ще добавим нещо ново.
Това което исках да ти обърна внимание е, че на Ц++ за да постигнеш същата функционалност със динамични списъци генерирани по време на изпълнението на конструктори на статични обекти ще отнеме повече сорс и ще генерира повече код. Разбира се, че ще стане, ама защо?
Между другото както и Веско сам каза, проблема въобще не му е във времето за обхождане. Трудно ми е да си представя, че има повече от 20-30 функции в този списък - ако има, то има сериозен дизайн проблем на системата и трябва да започне от там да оправя. 20-30 функции даже и при клок 2МХц се обхождат далече под 1мс, т.е. проблема му е в самите функции които вика - може да има няккакво чакане вътре (хардуер, мутекс), или техния брой наистина е безобразно много. Но определено не е в начина по който се генерира и обхожда този списък. Виж ние с теб можем да си чешем езиците колкото искаме, ама едва ли ще му решим истински проблем

Само да добавя, че ако пусна фулл оптимизация на ГЦЦ-то нямам проблем Просто кода дето генерира ГЦЦ-то без грам оптимизация си е голяма боза.

Повече код от какво?
Не може да сравняваш ябълки с портокали... Ако решиш да ползваш динамична функционалност то кодът ти няма как принципно да е много различен, без значение на какво си го писал.

Иначе за Веско не се притеснявай, познаваме се... най-вероятно вече си е решил проблема, а и да не е ще го реши, нямам никакви съмнения
И аз си мисля че нещо изпуска... обхождането и викането не ми се вярва да го бави чак толкова...

Едно късно включване и от мен.


Същото се ползва в Linux ядрото за инициализация на модулите.


С прагми няма как да стане, мисля. Но може да стане елементарно с още едно dependency в makefile-а, в което от простичък текстов файл с произволен скриптов език си добавяш желаните секции към линкер-скрипт заготовка.

Те това ако му казваш просто

Иначе линкера за някой секции генеира служебно __start_SECTNAME и __end_SECTNAME. Лощото (за сега) е че това става само за секциите, които не съм описал в скрипт-а и линк-а ми ги слага в рам-а... Трябва само да измисля начин да ми ги слага във флаша

Така го виждам. Желаните секции (списъци) в един текстов файл по един на ред, и оттам дори shell скрипт-а за 5 минути ще нахвърляш. Makefile добавката е два-три реда.
Поне не ми се вижда по-сложно от това да пишеш прагми за всяка секция, разхвърляни във всеки сорс.


Ползвай wildcard ако позволяват имената.

Тарикатски wildcards в името на секцията не помага ли?

А това с простичкия текстов файл не е чак толкова трудно ако си под линукс
С един греп/сед минаваш през всички сорсове и търсиш някакъв вери спешъл макрос или коментар, трупаш всичко в един файл, после този файл го сортираш, махаш дублираните редове и го инклудваш в линкерския скрипт. Ще ти отнеме най много час два кютане по документацията на тууловете и малко псуване. grep sed sort uniq make ...
EDIT: писали сме заедно с woody ...

злите езици говорят, че подобни символи се генерират стига да ги имаш и декларирани като валидни С идентификатори...

Това направо вуду магия ... само с баене едва ли щеше да се оправи

Линкерските символи нямаш грижа да ги резолвираш в 'C', само трябва да ги обявиш. Това е основната идея. Ама нямах спомен че автоматично генерира start/end.
Така че и този подход също върши работа.

Аз успях и да ги използвам...
#define __ON_INIT(x) void x (void); \
void * x##_p __attribute__ ((section("MSG_ON_INIT"))) = & x; \
void x (void)

extern char *__start_MSG_ON_INIT;
extern char * __stop_MSG_ON_INIT;

__ON_INIT(alabala)
{

}

__ON_INIT(alabala1)
{

}

memcpy(bbb, __start_MSG_ON_INIT, 10);
memcpy(bbb, __stop_MSG_ON_INIT, 10);

(memcpy-то е само за да проверя за грешки на линк-а)


Обаче, още не съм се научил да контролирам къде линка ще ми сложи секциите...

Е, то само ако това ти е проблема, брой го за решен ... не ми се рови сега за примери, но има колкото искаш в гугле. Предполагам, че Миро или някой от останалите колеги може да ти даде веднага нещо за сламка.

Секциите дето се споменават в сосрсовете се наричат "входни" секции. В линкерския скрипт се описват "изходни" секции плюс правила кои входни секции да се натъпчат в съответната изходна секция.
Казано по друг начин, една или повече входни секции отиват в една изходна секция, като се разполагат последователно или може сортирано по име... На изходните секции може да се задават адреси (физически или виртуални). А може и да не се задават, просто новата изходна секция ще почне след края на предната...

И пак част от решението са wildcards за входните секции.