¿Por qué usar una variable int para un pin cuando const int, enum o #define tiene mucho más sentido?

¿Por qué las personas usan una variable para especificar un número de pin cuando es poco probable que el pin cambie durante la ejecución del código?

Muchas veces veo un intser utilizado para una definición de pin,

int led = 13;

cuando el uso de un const int

const int led = 13;

o enum, o#define

#define LED 13

Tiene mucho más sentido.

Incluso está en los tutoriales en el sitio de Arduino, por ejemplo, el primer tutorial que ejecuta la mayoría de la gente, Blink .

Me leído en alguna parte que const intse prefiere sobre #define. ¿Por qué no se fomenta esto desde el principio, en lugar de permitir que las personas desarrollen malos hábitos desde el principio? Lo noté hace un tiempo, pero recientemente ha comenzado a irritarme, de ahí la pregunta.

Memoria / procesamiento / computación inteligente es una const int, enumo para el caso #define, mejor que una llanura int, es decir, ocupa menos memoria, almacenado en memoria diferentes (Flash, EEPROM, SRAM), más rápida ejecución, más rápido para compilar?

Esto puede parecer un duplicado de ¿Es mejor usar #define o const int para constantes? , pero estoy abordando la pregunta de por qué las personas usan variables y cómo mejora el rendimiento cuando no lo hacen, en lugar de qué tipo de constante es mejor.

const int led = 13;

Ese es el método correcto. O incluso:

const byte led = 13;

¿Cuántos pines tienes?

Algunos de los tutoriales no pasaron por tanto control de calidad como podrían haberlo hecho.

El rendimiento será mejor usando const byte, en comparación, intsin embargo, el compilador puede ser lo suficientemente inteligente como para darse cuenta de lo que está haciendo.

Lo que puede hacer es alentar suavemente a las personas a usar técnicas más eficientes al usarlas en su propio código.

Respuestas a comentarios

1. Un comentarista ha sugerido que byteno es el estándar C. Esto es correcto, sin embargo, este es un sitio de Arduino StackExchange, y creo que es aceptable usar los tipos estándar proporcionados por el IDE de Arduino.

   En Arduino.h hay esta línea:

   typedef uint8_t byte;

   Tenga en cuenta que esto no es exactamente lo mismo que unsigned char. Ver uint8_t vs unsigned char y ¿ Cuándo es uint8_t ≠ unsigned char? .

2. Otro comentarista ha sugerido que el uso de byte no necesariamente mejorará el rendimiento, porque los números menores a los que intse promocionarán int(consulte Reglas de promoción de enteros si desea obtener más información al respecto).

   Sin embargo, en el contexto de un identificador constante , el compilador generará un código eficiente en cualquier caso. Por ejemplo, desarmar "parpadeo" le da esto en la forma original:

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

   De hecho, genera el mismo código si 13:

   • Es un literal
   • Es un #define
   • Es un const int
   • Es un const byte

El compilador sabe cuándo puede caber un número en un registro y cuándo no. Sin embargo, es una buena práctica usar una codificación que indique su intención . Dejarlo en constclaro deja claro que el número no cambiará, y dejarlo claro byte(o uint8_t) deja claro que espera un número pequeño.

Mensajes de error confusos

Otra razón importante para evitar #definees los mensajes de error que recibe si comete un error. Considere este bosquejo de "parpadeo" que tiene un error:

#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 la superficie se ve bien, pero genera estos mensajes de error:

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

Miras la primera línea resaltada (línea 4) y ni siquiera ves un símbolo "=". Además, la línea se ve bien. Ahora es bastante obvio cuál es el problema aquí ( = 13se está sustituyendo LED), pero cuando la línea está 400 líneas más abajo en el código, no es obvio que el problema esté en la forma en que se define el LED.

He visto a personas caer en esto muchas veces (incluido yo mismo).

Como Ignacio dice correctamente, es básicamente porque no saben mejor. Y no saben mejor porque las personas que les enseñaron (o los recursos que usaron cuando aprendieron) no sabían mejor.

Gran parte del código y los tutoriales de Arduino están escritos por personas que nunca han recibido capacitación en programación y son muy "autodidactas" de los recursos de personas que son muy autodidactas sin la capacitación adecuada en programación.

Muchos de los fragmentos de código tutorial que veo alrededor del lugar (y especialmente aquellos que solo están disponibles en los videos de YouTube --- urgh) serían una marca de falla si los marcara en un examen.

Sí, constse prefiere a sobre una no constante, e incluso sobre una #define, porque:

• A const(como a #define, a diferencia de un no constante) no asigna ninguna RAM
• A const(como un no constante, pero a diferencia de a #define) le da al valor un tipo explícito

El segundo punto allí es de particular interés. A menos que se indique específicamente lo contrario con la conversión de tipos incrustada ( (long)3) o un sufijo de tipo ( 3L) o la presencia de un punto decimal ( 3.0), #defineun número siempre será un número entero y todas las matemáticas realizadas en ese valor serán como si fuera un entero. La mayoría de las veces eso no es un problema, pero puede encontrarse con escenarios interesantes cuando intenta #defineun valor que es más grande de lo que un entero puede almacenar, como #define COUNT 70000y luego realizar una operación matemática con otros intvalores. Al usar un const, puede decirle al compilador "Este valor debe tratarse como este tipo de variable", por lo que en su lugar usaría: const long count = 70000;y todo funcionaría como se esperaba.

También tiene el efecto knock-on que comprueba el tipo al pasar el valor alrededor del lugar. Intente pasar un const longa una función que espera un inty se quejaría de reducir el rango de variables (o incluso no compilará por completo según el escenario). Haga eso con un #definey simplemente continuaría silenciosamente dándole los resultados incorrectos y lo dejaría rascándose la cabeza durante horas.

Como novato de 2 semanas en Arduino, retomaría la idea general de que Arduino está ocupado por no programadores. La mayoría de los bocetos que he examinado, incluidos los del sitio de Arduino, muestran una falta total de orden, con bocetos que no funcionan y apenas un comentario coherente a la vista. Los diagramas de flujo no existen, y las "Bibliotecas" son un revoltijo no moderado.

Mi respuesta es ... lo hacen porque funciona. Me cuesta mucho no hacer una pregunta en mi respuesta como "¿por qué tiene que estar 'equivocado'?"