Cette question a été faite à mort et je conviendrais que les études sont la voie à suivre. Cependant, je suis curieux de savoir comment les énormes compilent dans le code final-defines ne sont que des remplacements de chaînes, mais que je ajoute quelque chose au binaire compilé? Ou sont-ils tous deux équivalents à ce stade? Lorsque l'écriture de micrologiciels et de mémoire est très limitée, y a-t-il un avantage, peu importe la petite taille, utiliser #defines? P>
Merci! P>
éditer: comme demandé par le commentaire ci-dessous, par intégré, je veux dire un appareil photo numérique. P>
Merci pour les réponses! Je suis tout pour Enums! P>
3 Réponses :
Un Enum code> est juste un entier, finalement. Le compilateur propage les valeurs, comme pour un
const code>. P>
Une valeur code> Enum code> est une expression constante i>, tandis qu'une variable const code> (en C) n'est pas et ne peut donc pas être utilisée pour l'initialisation statique,
case code> étiquettes, ...;; Un
ENUM code> est une constante de la compilation, une variable
const code> est une constante d'exécution (du point de vue de la langue - le compilateur est libre de faire une propagation constante pour
Const code> variables)
Un énumé est juste un "INT", en particulier. Au moins la GCC traite enums par défaut comme une valeur de 32 bits, même sur des MCU 16 bits ou 8 bits. Pour utiliser le plus petit type possible, il faut spécifier l'option -fshort-Enums pour la compilation.
(à la fin de la modification), cela est particulièrement important lorsqu'il est utilisé comme argument de fonction: FUNC (VALEUR ENUM) CODE> Compile pire (par défaut) que
FUNC (valeur UNIT8_T) CODE> ET Passage une valeur définie.
Il est impossible de dire sans profilage ni mesurer d'une autre manière. P>
Mais, tout compilateur décent ne montrera aucune différence significative. En outre, vous devriez toujours préférer le code lisible et typographique sur un code efficace, illisible et gotha-monté. Ne commencez pas à optimiser l'efficacité sur la lisibilité jusqu'à ce que vous ayez prouvé deux choses: p>
Je suis complètement d'accord avec vous sur une optimisation inutile! Je viens de rejoindre un projet et #define était utilisé, alors je me demandais s'il pouvait une raison d'efficacité.
Dans ce cas, vous n'avez probablement pas besoin de faire du profilage et de mesurer en tant que tel - il suffit de regarder l'assemblage généré, qui devrait être identique.
Les deux sont expressions constantes em> dans la terminologie de la norme, ils "devraient" être évalués pleinement à la compilation de la compilation de la compilation. Il faudrait un compilateur malicieusement pathologique pour générer un code différent. P>
Ils ne sont pas seulement expressions constantes i> mais des expressions constantes entier i> dans la terminologie de la norme. La différence est importante ici, car pour la première paragir, une constante d'adresse serait également admissible. Seulement en étant le plus tard, ils peuvent apparaître dans des déclarations de type et pour la définition d'autres Enum code> constantes. Et utilisé comme longueur de matrice, ils font la différence entre les tableaux simples et la VLA.
@nqtronix: Je ne vois pas comment ce commentaire concerne ma réponse (ou à la question).
@R .. mon mauvais, je voulais commenter la réponse ci-dessous. Je l'ai réparé et ajouté des éclaircissements.
"Embedded" peut signifier n'importe quoi d'un Nexus S à un système avionique. Vous devriez l'affiner (quelle puce, quel compilateur, quelle version?) Si vous voulez une réponse significative. Je suis d'accord avec les intervenants que devrait être traité i> être traité comme un
const code>.
@Matthew: Je pense que vous pensez à C ++. En C,
#define code> et
Enum code> peut créer des expressions constantes, mais une variable
const code> n'est jamais une expression constante et l'accès à ce qu'il incitera presque sûrement Taille du code réel et pénalités de performance (le chargement de la mémoire).
@R, vous avez raison sur un
const code> ne pas être une expression de const en C99 (et j'ai besoin de relire cela). Mais dans des cas simples, le compilateur peut toujours éviter d'attribuer la mémoire pour eux. Par exemple, si je mets
const int a = 1; code> dans un en-tête, alors
int b = a; code> dans Main, le compilateur peut être i> assez intelligent pour ne pas allouer la mémoire pour
A code>.
Habituellement, le compilateur évitera ce type de smarts pour la compatibilité avec des hacks de liaison traditionnels qui pourraient remplacer le symbole.
@Mathew: Je ne pense pas que la question soit particulièrement spécifique à "intégrée" dans tous les cas et quelles puce / compilateur ou quoi que ce soit ne devrait faire aucune différence, c'est une question plus générale.