Po co używać zmiennej int dla pinu, gdy const int, enum lub #define ma o wiele większy sens

Dlaczego ludzie używają zmiennej, aby określić numer PINu, gdy jest mało prawdopodobne, że PIN zmieni się podczas wykonywania kodu?

Wiele razy widzę, intże używa się definicji pinów,

int led = 13;

kiedy użycie a const int

const int led = 13;

lub enumlub#define

#define LED 13

ma znacznie większy sens.

Jest nawet w tutorialach na stronie Arduino, na przykład w pierwszym tutorialu, który uruchamia większość ludzi, Blink .

Ja czytałem gdzieś , że const intjest korzystniejszy #define. Dlaczego nie zachęca się tego od samego początku, zamiast pozwolić ludziom od samego początku rozwijać złe nawyki? Zauważyłem to jakiś czas temu, ale ostatnio zaczęło mnie to irytować, stąd pytanie.

Pamięć / przetwarzanie / computing mądry jest const int, enumlub o to chodzi #define, lepiej niż zwykły int, czyli zajmuje mniej pamięci, przechowywane w innej pamięci (Flash, EEPROM, SRAM), szybsze wykonanie, szybciej skompilować?

Może się to wydawać duplikatem Czy lepiej używać #define lub const int dla stałych? , ale odpowiadam na pytanie, dlaczego ludzie używają zmiennych, i jak poprawia się wydajność, gdy tego nie robią, zamiast tego, który typ stałej jest lepszy.

const int led = 13;

To jest poprawna metoda. Lub nawet:

const byte led = 13;

Ile masz szpilek?

Niektóre samouczki nie poddały się tak dużej kontroli jakości, jak mogą.

Wydajność będzie lepsza w użyciu const byte, w porównaniu z inttym, że kompilator może być wystarczająco inteligentny, aby zrozumieć, co robisz.

To, co możesz zrobić, to delikatnie zachęcić ludzi do korzystania z bardziej wydajnych technik, używając ich we własnym kodzie.

Odpowiedzi na komentarze

1. byteKomentator zasugerował, że nie jest to standard C. Jest to poprawne, jednak jest to strona Arduino StackExchange i uważam, że użycie standardowych typów dostarczanych przez Arduino IDE jest dopuszczalne.

   W Arduino.h jest ta linia:

   typedef uint8_t byte;

   Pamiętaj, że nie jest to dokładnie to samo co unsigned char. Zobacz uint8_t vs unsigned char i Kiedy uint8_t ≠ unsigned char? .

2. Inny komentator zasugerował, że użycie bajtu niekoniecznie poprawi wydajność, ponieważ liczby mniejsze niż intbędą promowane int(patrz Zasady promocji liczb całkowitych, jeśli chcesz więcej na ten temat).

   Jednak w kontekście identyfikatora stałej kompilator generuje wydajny kod w każdym przypadku. Na przykład deasemblacja „mrugnięcia” daje to w oryginalnej formie:

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

   W rzeczywistości generuje ten sam kod, czy 13:

   • Jest dosłowne
   • Jest #define
   • Jest const int
   • Jest const byte

Kompilator wie, kiedy może zmieścić liczbę w jednym rejestrze, a kiedy nie. Jednak dobrą praktyką jest stosowanie kodowania, które wskazuje na twoje zamiary . Wyjaśnienie tego constjasno pokazuje, że liczba się nie zmieni, a wyjaśnienie byte(lub uint8_t) wyjaśnia, że ​​oczekujesz małej liczby.

Mylące komunikaty o błędach

Innym ważnym powodem, dla którego należy unikać, #definesą komunikaty o błędach wyświetlane w przypadku pomyłki. Rozważmy ten szkic „mrugnięcia”, który zawiera błąd:

#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);              
}

Na powierzchni wygląda OK, ale generuje te komunikaty o błędach:

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

Patrzysz na pierwszą podświetloną linię (linia 4) i nawet nie widzisz symbolu „=”. Dodatkowo linia wygląda dobrze. Teraz dość oczywiste jest, na czym polega problem ( = 13jest zastępowany LED), ale gdy linia znajduje się 400 linii dalej w kodzie, nie jest oczywiste, że problem dotyczy sposobu definiowania diody LED.

Widziałem ludzi zakochanych wiele razy (w tym siebie).

Jak słusznie stwierdza Ignacio, dzieje się tak głównie dlatego, że nie wiedzą lepiej. I nie wiedzą lepiej, ponieważ ludzie, którzy ich nauczali (lub zasoby, których używali podczas nauki) nie wiedzieli lepiej.

Znaczna część kodu i samouczków Arduino jest pisana przez ludzi, którzy nigdy nie mieli żadnego szkolenia w programowaniu i są bardzo „samoukami” z zasobów przez ludzi, którzy sami są bardzo samoukami bez odpowiedniego szkolenia w programowaniu.

Wiele fragmentów kodu samouczka, które widzę w tym miejscu (a zwłaszcza te, które są dostępne tylko w filmach na YouTube --- urgh) byłby znakiem nieudanym, gdybym zaznaczał je na egzaminie.

Tak, a constjest preferowane zamiast non-const, a nawet ponad a #define, ponieważ:

• A const(jak a #define, w przeciwieństwie do non-const) nie przydziela pamięci RAM
• A const(jak non-const, ale w przeciwieństwie do a #define) nadaje wartości jawny typ

Drugi punkt jest szczególnie interesujący. O ile nie powiedziano inaczej z osadzonym rzutowaniem typu ( (long)3) lub sufiksem typu ( 3L) lub obecnością kropki dziesiętnej ( 3.0), #definea liczby zawsze będzie liczbą całkowitą, a cała matematyka wykonana na tej wartości będzie tak, jakby była liczba całkowita. Przez większość czasu nie stanowi to problemu, ale możesz natknąć się na ciekawe scenariusze, gdy próbujesz #defineuzyskać wartość większą niż liczba całkowita, którą można zapisać, na przykład #define COUNT 70000wykonać następnie operację matematyczną z innymi intwartościami. Używając a, constmożesz powiedzieć kompilatorowi: „Tę wartość należy traktować jako ten typ zmiennej” - więc zamiast tego użyjesz: const long count = 70000;i wszystko będzie działać zgodnie z oczekiwaniami.

Ma również efekt domina, który sprawdza typ podczas przekazywania wartości wokół miejsca. Spróbuj przekazać a const longdo funkcji, która spodziewa się, inti narzekałaby na zawężenie zakresu zmiennych (lub nawet całkowicie nie skompilowała się w zależności od scenariusza). Zrób to za pomocą #definea, a po prostu w ciszy nadal będzie dawał złe wyniki i pozostawiasz drapanie się przez wiele godzin.

Jako 2-tygodniowy nowicjusz w Arduino podjąłem ogólną ideę zajmowania Arduino przez nie-programistów. Większość szkiców, które zbadałem, w tym te na stronie Arduino, wykazuje całkowity brak porządku, przy czym szkice nie działają i ledwo widzę spójny komentarz. Schematy blokowe nie istnieją, a „Biblioteki” to niemoderowana zbieranina.

Moja odpowiedź brzmi ... robią to, ponieważ to działa. Trudno mi nie zadać pytania w odpowiedzi, na przykład „dlaczego to musi być„ złe ”?”