Alternative/Strumenti per la # define inferno C/C++

nel nostro progetto C/C++ usiamo un colpo di testa di configurazione (~ 1000 linee), che è pieno di # ifdef e di #definesAlternative/Strumenti per la # define inferno C/C++

#if (defined(HW_1) || defined(SOME_TECHNOLOGY_SUPPORTED)) && defined(OTHER_TECHNOLOGY_SUPPORTED) 
#define SOME_FEATURE_AVAILABLE 
#endif

Nella nostra configurazione di generazione abbiamo predefinite alcune definizioni che vengono passate al compilatore. Ciò si traduce in diverse definizioni (come SOME_FEATURE_AVEILABLE) nella nostra intestazione di configurazione.

Poiché la nostra intestazione di configurazione è abbastanza grande, c'è anche un po 'di confusione.

Ci sono alternative per questo inferno #define?

Oppure ci sono strumenti che aiutano a vedere in che casi vengono definiti i set.

Stiamo sviluppando il firmware incorporato in modo che non possiamo sostituire la compilazione condizionale di runtime se lo è.

fonte

2013-08-08 woodtluk

Su quale sistema si compila. Per quale sistema operativo? Cerca 'autoconf' e' autotools' .... –

Se ti limiti ad ANSI C89 e ISO C++ 98, non ne hai bisogno. –

Tuttavia, il compilatore può essere in grado di ottimizzare se condizionali se si definiscono i valori const statici. – Frodo

Se tutti i tuoi #define si trovano in un unico file di configurazione, puoi provare a eseguire una compilazione solo con il preprocessore e quindi trovare tutte le macro definite. Per esempio,

$ gcc -DFEATURE1 -DFEATURE2 -E configuration.h | grep '#define'

fonte

2013-08-09 01:10:15

si potrebbe desiderare di leggere e prendere in considerazione la progettazione basata su policy C++ (http://en.wikipedia.org/wiki/Policy-based_design) introdotto da Alexandrescu nel suo libro "moderno C++ Design".

fonte

2013-08-25 17:05:22 JohnB

Preferisco il pattern "bridge" alla progettazione basata su policy: raggiunge lo stesso obiettivo senza modelli o eredità multipla. – Michael

Suppongo che bridge incoraggi un sovraccarico di runtime (?). La progettazione basata su criteri (usando i modelli) non lo fa. L'ereditarietà multipla non causa problemi qui, poiché non gestisci oggetti come oggetti di classe base (non li trattano in modo polimorfico). – JohnB

Alternative/Strumenti per la # define inferno C/C++

risposta

Problemi correlati