Pourquoi utiliser une variable int pour une broche lorsque const int, enum ou #define est beaucoup plus logique

Pourquoi les gens utilisent-ils une variable pour spécifier un numéro de code PIN lorsque le code PIN est peu susceptible de changer tout au long de l'exécution du code?

Plusieurs fois, je vois un intêtre utilisé pour une définition de broche,

int led = 13;

lorsque l'utilisation d'un const int

const int led = 13;

ou enum, ou#define

#define LED 13

est beaucoup plus logique.

C'est même dans les tutoriels sur le site Arduino, par exemple, le premier tutoriel que la plupart des gens exécutent, Blink .

J'ai lu quelque part qui const intest préféré à #define. Pourquoi cela n'est-il pas encouragé dès le début, plutôt que de permettre aux gens de développer de mauvaises habitudes, dès le départ? Je l'ai remarqué il y a quelque temps, mais récemment, il a commencé à m'énerver, d'où la question.

En ce qui concerne la mémoire / le traitement / l'informatique, est-ce que const int, enumou d'ailleurs #define, mieux qu'une simple int, c'est-à-dire occupe moins de mémoire, stockée dans une mémoire différente (Flash, EEPROM, SRAM), exécution plus rapide, compilation plus rapide?

Cela peut sembler être un doublon de Est-il préférable d'utiliser #define ou const int pour les constantes? , mais j'aborde la question de savoir pourquoi les gens utilisent des variables et comment les performances s'améliorent quand elles ne le font pas, plutôt que quel type de constante est meilleur.

const int led = 13;

C'est la bonne méthode. Ou même:

const byte led = 13;

Combien de broches avez-vous?

Certains didacticiels n'ont pas tout à fait subi autant de contrôle de la qualité qu'ils auraient pu.

Les performances seront meilleures à utiliser const byte, comparez à, intmais le compilateur peut être suffisamment intelligent pour réaliser ce que vous faites.

Ce que vous pouvez faire est d'encourager doucement les gens à utiliser des techniques plus efficaces en les utilisant dans votre propre code.

Réponses aux commentaires

1. Un commentateur a suggéré que ce byten'est pas la norme C. C'est correct, mais il s'agit d'un site Arduino StackExchange, et je pense que l'utilisation de types standard fournis par l'IDE Arduino est acceptable.

   Dans Arduino.h, il y a cette ligne:

   typedef uint8_t byte;

   Notez que ce n'est pas exactement le même que unsigned char. Voir uint8_t vs caractère non signé et quand uint8_t char caractère non signé? .

2. Un autre intervenant a suggéré que l'utilisation d'octets n'améliorera pas nécessairement les performances, car des nombres plus petits que ceux intqui seront promus int(voir Règles de promotion d'entiers si vous en voulez plus).

   Cependant, dans le contexte d'un identificateur const , le compilateur générera un code efficace dans tous les cas. Par exemple, le démontage du "clignotement" donne ceci sous la forme originale:

   00000086 <loop>:
     86:   8d e0           ldi r24, 0x0D   ; 13
     88:   61 e0           ldi r22, 0x01   ; 1
     8a:   1b d1           rcall   .+566       ; 0x2c2 <digitalWrite>

   En fait, il génère le même code que 13:

   • Est un littéral
   • Est un #define
   • Est un const int
   • Est un const byte

Le compilateur sait quand il peut rentrer un nombre dans un registre et quand il ne le peut pas. Cependant, il est recommandé d'utiliser un codage qui indique votre intention . Le faire constindique clairement que le nombre ne changera pas et le fait byte(ou uint8_t) indique clairement que vous attendez un petit nombre.

Messages d'erreur déroutants

Une autre raison majeure à éviter #defineest les messages d'erreur que vous obtenez si vous faites une erreur. Considérez ce croquis "clignotant" qui a une erreur:

#define LED = 13;

void setup() {
  pinMode(LED, OUTPUT);      // <---- line with error
}

void loop() {
  digitalWrite(LED, HIGH);   // <---- line with error 
  delay(1000);             
  digitalWrite(LED, LOW);    // <---- line with error
  delay(1000);              
}

En surface, il semble OK, mais il génère ces messages d'erreur:

Blink.ino: In function ‘void setup()’:
Blink:4: error: expected primary-expression before ‘=’ token
Blink:4: error: expected primary-expression before ‘,’ token
Blink:4: error: expected `;' before ‘)’ token
Blink.ino: In function ‘void loop()’:
Blink:8: error: expected primary-expression before ‘=’ token
Blink:8: error: expected primary-expression before ‘,’ token
Blink:8: error: expected `;' before ‘)’ token
Blink:10: error: expected primary-expression before ‘=’ token
Blink:10: error: expected primary-expression before ‘,’ token
Blink:10: error: expected `;' before ‘)’ token

Vous regardez la première ligne en surbrillance (ligne 4) et ne voyez même pas de symbole "=". De plus, la ligne semble bien. Maintenant, il est assez évident de savoir quel est le problème ici ( = 13est remplacé LED), mais lorsque la ligne se trouve 400 lignes plus loin dans le code, il n'est pas évident que le problème réside dans la façon dont la LED est définie.

J'ai vu des gens tomber à plusieurs reprises (y compris moi-même).

Comme le dit à juste titre Ignacio, c'est essentiellement parce qu'ils ne savent pas mieux. Et ils ne savent pas mieux parce que les gens qui les ont enseignés (ou les ressources qu'ils ont utilisées pour apprendre) ne savaient pas mieux.

Une grande partie du code Arduino et des didacticiels sont rédigés par des personnes qui n'ont jamais reçu de formation en programmation et sont très "autodidactes" à partir de ressources par des personnes qui sont elles-mêmes très autodidactes sans formation appropriée en programmation.

De nombreux extraits de code de didacticiel que je vois autour de moi (et en particulier ceux qui ne sont disponibles que dans les vidéos YouTube --- urgh) seraient une note d'échec si je les notais lors d'un examen.

Oui, a constest préféré à un non-const, et même à a #define, car:

• A const(comme un #define, contrairement à un non-const) n'alloue pas de RAM
• A const(comme un non-const, mais contrairement à a #define) donne à la valeur un type explicite

Le deuxième point est particulièrement intéressant. Sauf indication contraire avec le transtypage de type intégré ( (long)3) ou un suffixe de type ( 3L) ou la présence d'un point décimal ( 3.0), #defineun nombre sera toujours un entier et toutes les mathématiques effectuées sur cette valeur seront comme s'il s'agissait d'un entier. La plupart du temps, ce n'est pas un problème, mais vous pouvez rencontrer des scénarios intéressants lorsque vous essayez #defineune valeur plus grande qu'un entier peut stocker, comme #define COUNT 70000et ensuite effectuer une opération mathématique avec d'autres intvaleurs. En utilisant un, constvous pouvez dire au compilateur "Cette valeur doit être traitée comme ce type de variable" - vous utiliseriez donc à la place: const long count = 70000;et tout fonctionnerait comme prévu.

Il a également pour effet d'activer le contrôle du type lors du passage de la valeur autour de l'endroit. Essayez de passer un const longà une fonction qui attend un intet il se plaindrait de réduire la plage de variables (ou même de ne pas compiler complètement selon le scénario). Faites cela avec un #defineet cela continuerait silencieusement à vous donner les mauvais résultats et vous laisserait vous gratter la tête pendant des heures.

En tant que débutant de 2 semaines pour Arduino, je reprendrais l'idée générale qu'Arduino est occupé par des non-programmeurs. La plupart des croquis que j'ai examinés, y compris ceux du site Arduino, montrent un manque total d'ordre, avec des croquis qui ne fonctionnent pas et à peine un commentaire cohérent en vue. Les organigrammes sont inexistants et les "bibliothèques" sont un fouillis non modéré.

Ma réponse est ... ils le font parce que ça marche. J'ai du mal à ne pas poser de question dans ma réponse telle que "pourquoi faut-il que ce soit" faux "?"