ทำไมต้องใช้ตัวแปร int สำหรับพินเมื่อ const int, enum หรือ #define เหมาะสมกว่า

เหตุใดผู้คนจึงใช้ตัวแปรเพื่อระบุหมายเลขพินเมื่อพินไม่น่าจะเปลี่ยนแปลงตลอดการประมวลผลของรหัส?

หลายครั้งที่ฉันเห็นสิ่งintที่ใช้สำหรับการกำหนดพิน

int led = 13;

เมื่อมีการใช้ const int

const int led = 13;

หรือenumหรือ#define

#define LED 13

ทำให้รู้สึกมากขึ้น

มันก็ยิ่งในบทเรียนบนเว็บไซต์ Arduino ตัวอย่างเช่นคนแรกที่กวดวิชาที่คนส่วนใหญ่เรียกใช้การกะพริบตา

ผมอ่านบางที่เป็นที่ต้องการมากกว่าconst int #defineทำไมสิ่งนี้ไม่ได้รับการสนับสนุนตั้งแต่เริ่มต้นแทนที่จะปล่อยให้คนพัฒนานิสัยที่ไม่ดีตั้งแต่ต้น? ฉันสังเกตเห็นว่ามันกลับมาสักพักหนึ่ง แต่เมื่อเร็ว ๆ นี้มันเริ่มทำให้ฉันหงุดหงิด

หน่วยความจำ / / การประมวลผลคอมพิวเตอร์ฉลาดเป็นconst int, enumหรือสำหรับเรื่องที่#defineดีกว่าธรรมดาintเช่นหมกมุ่นอยู่กับหน่วยความจำน้อยที่เก็บไว้ในหน่วยความจำที่แตกต่างกัน (Flash, EEPROM, SRAM) การดำเนินการได้เร็วขึ้นเร็วขึ้นเพื่อรวบรวม?

สิ่งนี้อาจดูเหมือนซ้ำซ้อนกับการใช้ #define หรือ const int สำหรับค่าคงที่หรือไม่ แต่ฉันกำลังพูดถึงคำถามที่ว่าทำไมผู้คนถึงใช้ตัวแปรและประสิทธิภาพการทำงานดีขึ้นอย่างไรเมื่อไม่ใช้แทนที่จะเป็นค่าคงที่แบบไหนดีกว่า

const int led = 13;

นั่นคือวิธีที่ถูกต้อง หรือแม้กระทั่ง:

const byte led = 13;

คุณมีพินกี่อัน?

บทเรียนบางบทไม่ผ่านการควบคุมคุณภาพเท่าที่ควร

ประสิทธิภาพจะดีขึ้นเมื่อใช้const byteเปรียบเทียบกับintคอมไพเลอร์อาจฉลาดพอที่จะรู้ว่าคุณกำลังทำอะไรอยู่

สิ่งที่คุณสามารถทำได้คือกระตุ้นให้ผู้คนใช้เทคนิคที่มีประสิทธิภาพมากขึ้นโดยใช้พวกเขาในรหัสของคุณเอง

ตอบสนองต่อความคิดเห็น

1. ผู้แสดงความคิดเห็นแนะนำว่าbyteไม่เป็นมาตรฐาน C นี่ถูกต้อง แต่นี่เป็นเว็บไซต์ Arduino StackExchange และฉันเชื่อว่าการใช้ประเภทมาตรฐานที่จัดทำโดย Arduino IDE นั้นเป็นที่ยอมรับ

   ใน Arduino.h มีบรรทัดนี้:

   typedef uint8_t byte;

   โปรดทราบว่านี่ไม่เหมือนกันunsigned charทุกประการ ดูuint8_t เทียบกับถ่านที่ไม่ได้ลงชื่อและuint8_t char ถ่านที่ไม่ได้ลงชื่อเมื่อใด .

2. ผู้แสดงความคิดเห็นคนอื่นแนะนำว่าการใช้ไบต์จะไม่จำเป็นต้องปรับปรุงประสิทธิภาพเนื่องจากตัวเลขที่เล็กกว่าintจะได้รับการเลื่อนขั้นเป็นint(ดูกฎการส่งเสริมการขายแบบจำนวนเต็มหากคุณต้องการข้อมูลเพิ่มเติม)

   อย่างไรก็ตามในบริบทของตัวระบุconstคอมไพเลอร์จะสร้างรหัสที่มีประสิทธิภาพในทุกกรณี ตัวอย่างเช่นการแยกส่วน "กะพริบ" ให้สิ่งนี้ในรูปแบบเดิม:

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

   ในความเป็นจริงมันสร้างรหัสเดียวกันไม่ว่าจะเป็น13:

   • เป็นตัวอักษร
   • คือ #define
   • คือ const int
   • คือ const byte

คอมไพเลอร์ทราบว่าสามารถใส่ตัวเลขลงในหนึ่งทะเบียนและเมื่อไม่สามารถทำได้ แต่มันเป็นวิธีที่ดีที่จะใช้การเข้ารหัสที่บ่งชี้ว่าคุณเจตนา การconstทำให้ชัดเจนว่าตัวเลขจะไม่เปลี่ยนแปลงและทำให้byte(หรือuint8_t) ทำให้ชัดเจนว่าคุณคาดหวังว่าจะมีจำนวนน้อย

ข้อความแสดงข้อผิดพลาดที่สับสน

อีกเหตุผลสำคัญที่ควรหลีกเลี่ยง#defineคือข้อความแสดงข้อผิดพลาดที่คุณได้รับหากคุณทำผิดพลาด พิจารณาภาพร่าง "กะพริบ" ซึ่งมีข้อผิดพลาด:

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

บนพื้นผิวมันก็โอเค แต่มันก็สร้างข้อความผิดพลาดขึ้นมา:

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

คุณดูที่บรรทัดที่ไฮไลต์แรก (บรรทัดที่ 4) และไม่เห็นแม้แต่สัญลักษณ์ "=" นอกจากนี้เส้นดูดี ตอนนี้มันค่อนข้างชัดเจนว่าปัญหาคืออะไรที่นี่ ( = 13กำลังถูกแทนที่ด้วยLED) แต่เมื่อบรรทัดคือ 400 บรรทัดต่อไปในรหัสมันไม่ชัดเจนว่าปัญหาคือวิธีการกำหนด LED

ฉันเคยเห็นคนตกหลุมรักมาหลายครั้งแล้ว (รวมถึงตัวฉันด้วย)

ในฐานะที่เป็นอิกนาชิโอมีสถานะที่ถูกต้องมันเป็นเพราะพวกเขาไม่รู้ดี และพวกเขาไม่รู้อะไรดีกว่าเพราะคนที่สอนพวกเขา (หรือแหล่งข้อมูลที่ใช้เมื่อเรียนรู้) ไม่รู้จักดีกว่า

รหัส Arduino และแบบฝึกหัด Arduino ส่วนใหญ่เขียนโดยผู้ที่ไม่เคยมีการฝึกอบรมเรื่องการเขียนโปรแกรมมาก่อนและมีการ "เรียนรู้ด้วยตนเอง" จากแหล่งข้อมูลโดยผู้ที่ตัวเองเป็นคนสอนตัวเองอย่างมาก

ตัวอย่างโค้ดสำหรับการกวดวิชาจำนวนมากที่ฉันเห็นรอบ ๆ สถานที่ (และโดยเฉพาะอย่างยิ่งที่มีเฉพาะในวิดีโอ YouTube --- urgh) จะเป็นเครื่องหมายล้มเหลวหากฉันทำเครื่องหมายพวกเขาในการสอบ

ใช่constเป็นที่ต้องการมากกว่าไม่ใช่ const และแม้กระทั่งมากกว่า#defineเพราะ:

• A const(เช่น a #defineซึ่งแตกต่างจาก non-const) ไม่ได้จัดสรร RAM ใด ๆ
• A const(เช่นไม่ใช่ const แต่แตกต่างจาก a #define) ให้ค่าประเภทที่ชัดเจน

จุดที่สองมีความสนใจเป็นพิเศษ เว้นแต่จะระบุไว้เป็นอย่างอื่นอย่างชัดเจนด้วยการฝังตัวการพิมพ์ ( (long)3) หรือคำต่อท้ายประเภท ( 3L) หรือการปรากฏตัวของจุดทศนิยม ( 3.0) #defineตัวเลขหนึ่งจะเป็นจำนวนเต็มเสมอและคณิตศาสตร์ทั้งหมดที่ดำเนินการกับค่านั้นจะเหมือนกับว่ามันเป็น จำนวนเต็ม. เวลาส่วนใหญ่ที่ไม่ใช่ปัญหา แต่คุณสามารถเรียกใช้ในสถานการณ์ที่น่าสนใจเมื่อคุณลอง#defineค่าที่มากกว่าจำนวนเต็มสามารถเก็บเช่น#define COUNT 70000จากนั้นทำการดำเนินการทางคณิตศาสตร์กับintค่าอื่น ๆ โดยใช้constคุณจะได้รับการบอกคอมไพเลอร์ "ค่านี้จะถือว่าเป็นตัวแปรประเภท" - ดังนั้นคุณจะใช้แทน: const long count = 70000;และทั้งหมดจะทำงานตามที่คาดไว้

นอกจากนี้ยังมีเอฟเฟกต์แบบน็อคออนที่จะตรวจสอบประเภทเมื่อส่งค่าไปรอบ ๆ สถานที่ ลองส่งผ่านconst longไปยังฟังก์ชั่นที่คาดว่าจะมีintและมันจะบ่นเกี่ยวกับการลดช่วงตัวแปร (หรือแม้กระทั่งล้มเหลวในการรวบรวมอย่างสมบูรณ์ขึ้นอยู่กับสถานการณ์) ทำอย่างนั้นด้วย#defineและมันก็จะดำเนินการอย่างเงียบ ๆ เพื่อให้คุณได้ผลลัพธ์ที่ผิดและทำให้คุณเกาหัวของคุณเป็นเวลาหลายชั่วโมง

ในฐานะที่เป็นมือใหม่สำหรับ Arduino 2 สัปดาห์ฉันจะรับความคิดทั่วไปของ Arduino ที่ถูกครอบครองโดยโปรแกรมเมอร์ที่ไม่ใช่ ภาพร่างส่วนใหญ่ที่ฉันได้ตรวจสอบรวมถึงภาพในเว็บไซต์ Arduino นั้นแสดงให้เห็นถึงการขาดคำสั่งโดยรวมด้วยภาพร่างที่ไม่ทำงานและแทบไม่แสดงความคิดเห็นที่ต่อเนื่องกันเลย แผนภูมิการไหลไม่มีอยู่จริงและ "ไลบรารี" นั้นมีความสับสนที่ไม่ได้ตรวจสอบ

คำตอบของฉันคือ ... พวกเขาทำเพราะใช้งานได้ ฉันมีเวลายากที่จะไม่ถามคำถามในคำตอบของฉันเช่น "ทำไมต้องเป็น 'ผิด'?