C ++ เหมาะสำหรับระบบฝังตัวหรือไม่

คำถามทั่วไปที่นี่และที่อื่น ๆ C ++ เหมาะสำหรับระบบฝังตัวหรือไม่

ไมโครคอนโทรลเลอร์? RTOSes? เครื่องปิ้งขนมปัง? พีซีแบบฝัง?

OOP มีประโยชน์กับไมโครคอนโทรลเลอร์หรือไม่

C ++ ลบโปรแกรมเมอร์ที่อยู่ห่างจากฮาร์ดแวร์มากเกินไปหรือไม่

C ++ ของ Arduino ควร (ที่ไม่มีการจัดการหน่วยความจำแบบไดนามิก, แม่แบบ, ข้อยกเว้น) ควรได้รับการพิจารณาว่าเป็น "C ++ จริง" หรือไม่?

(หวังว่าวิกินี้จะใช้เป็นสถานที่บรรจุสงครามศักดิ์สิทธิ์ที่มีศักยภาพนี้)

ใช่ C ++ ยังคงมีประโยชน์ในระบบฝังตัว อย่างที่คนอื่น ๆ บอกไว้มันยังคงขึ้นอยู่กับระบบของตัวเองเช่น uC แบบ 8 บิตอาจจะไม่มีในหนังสือของฉันแม้ว่าจะมีคอมไพเลอร์อยู่ที่นั่นและบางคนก็ทำ (ตัวสั่น) ยังคงมีข้อได้เปรียบในการใช้ C ++ แม้ว่าคุณจะลดระดับลงเป็นบางอย่างเช่น "C +" แม้ในโลกไมโคร 8 บิต ฉันหมายถึงอะไรโดย "C +" ผมหมายถึงไม่ได้ใช้ใหม่ / ลบหลีกเลี่ยงข้อยกเว้นให้หลีกเลี่ยงการเรียนเสมือนกับมรดกอาจจะหลีกเลี่ยงการรับมรดกทั้งหมดเข้าด้วยกันต้องระวังให้มากกับแม่แบบใช้ฟังก์ชั่นแบบอินไลน์แทนแมโครและใช้ตัวแปรแทนconst#defines

ฉันทำงานทั้งใน C และ C ++ ในระบบฝังตัวมานานกว่าทศวรรษแล้วและความกระตือรือร้นที่อ่อนเยาว์ของฉันสำหรับ C ++ ได้ลดลงอย่างแน่นอนเนื่องจากปัญหาในโลกแห่งความจริงที่สั่นคลอนความไร้เดียงสาของฉัน ฉันเห็นสิ่งที่เลวร้ายที่สุดของ C ++ ในระบบฝังตัวซึ่งฉันต้องการจะอ้างถึงว่า "โปรแกรมเมอร์ซีเอสก็บ้าคลั่งในโลก EE" ในความเป็นจริงนั้นเป็นสิ่งที่ฉันกำลังทำงานกับลูกค้าของฉันเพื่อปรับปรุง codebase นี้ที่พวกเขามีในหมู่คนอื่น

อันตรายของ C ++ เป็นเพราะมันเป็นเครื่องมือที่ทรงพลังมากเหมือนดาบสองคมที่สามารถตัดแขนและขาของคุณออกหากไม่ได้รับการศึกษาและฝึกฝนอย่างถูกต้องในภาษาและการเขียนโปรแกรมทั่วไป C เป็นเหมือนดาบสองคม แต่ก็ยังคมอยู่ ด้วย C ++ มันง่ายเกินไปที่จะได้ระดับสูงของ abstraction และสร้าง interface ที่สับสนซึ่งไม่มีความหมายในระยะยาวและนั่นเป็นส่วนหนึ่งเนื่องจาก C ++ มีความยืดหยุ่นในการแก้ปัญหาเดียวกันด้วยคุณสมบัติทางภาษาที่แตกต่างกัน (เทมเพลต OOP ขั้นตอน RTTI, OOP + เท็มเพลต, การบรรทุกเกินพิกัด, การทำอินไลน์)

ฉันเสร็จสิ้นการสัมมนา 4 ชั่วโมงเกี่ยวกับซอฟต์แวร์ฝังตัวใน C ++ โดยกูรู Meyers จาก C ++ เขาชี้ให้เห็นบางสิ่งเกี่ยวกับแม่แบบที่ฉันไม่เคยพิจารณามาก่อนและพวกเขาสามารถช่วยสร้างรหัสที่สำคัญต่อความปลอดภัยได้อีก สิ่งที่สำคัญคือคุณไม่สามารถมีรหัสตายในซอฟต์แวร์ที่ต้องเป็นไปตามข้อกำหนดด้านความปลอดภัยที่สำคัญอย่างเข้มงวด เทมเพลตสามารถช่วยให้คุณทำสิ่งนี้ได้เนื่องจากคอมไพเลอร์สร้างโค้ดที่จำเป็นเมื่อสร้างอินสแตนซ์เทมเพลตเท่านั้น อย่างไรก็ตามหนึ่งต้องมีการศึกษาอย่างละเอียดมากขึ้นในการใช้งานการออกแบบอย่างถูกต้องสำหรับคุณลักษณะนี้ซึ่งยากที่จะสำเร็จใน C เพราะ linkers ไม่ได้เพิ่มประสิทธิภาพรหัสตายเสมอ

Scott Meyers เป็นผู้สนับสนุนที่ใหญ่มากในเทมเพลตและการใช้อินไลน์อย่างรอบคอบและฉันต้องบอกว่าฉันยังสงสัยในการเป็นแม่แบบเกี่ยวกับเทมเพลต ฉันมักจะอายห่างจากพวกเขาแม้ว่าเขาจะบอกว่าพวกเขาควรจะใช้เฉพาะเมื่อพวกเขากลายเป็นเครื่องมือที่ดีที่สุด นอกจากนี้เขายังชี้ให้เห็นว่า C ++ ให้เครื่องมือในการสร้างอินเทอร์เฟซที่ดีและใช้งานง่ายและทำให้การใช้งานผิดพลาด นั่นเป็นส่วนที่ยาก เราต้องมีความเชี่ยวชาญในระดับ C ++ ก่อนที่คุณจะรู้วิธีการใช้คุณสมบัติเหล่านี้ในวิธีที่มีประสิทธิภาพมากที่สุดในการเป็นโซลูชั่นการออกแบบที่ดีที่สุด

เช่นเดียวกันสำหรับ OOP ในโลกที่ฝังตัวคุณต้องทำความคุ้นเคยกับโค้ดที่คอมไพเลอร์กำลังจะถ่มน้ำลายออกมาเพื่อทราบว่าคุณสามารถจัดการค่าใช้จ่ายในการดำเนินการของ polymorphism ในเวลาทำงานหรือไม่ คุณต้องเต็มใจที่จะทำการวัดเช่นกันเพื่อพิสูจน์การออกแบบของคุณว่าเป็นไปตามข้อกำหนดของคุณ คลาส InterruptManager ใหม่นั้นจะทำให้เวลาในการตอบสนองของฉันยาวเกินไปหรือไม่ มีรูปแบบอื่น ๆ ของความแตกต่างที่อาจจะพอดีกับปัญหาของคุณดีขึ้นเช่นการเชื่อมโยงความแตกต่างเวลาที่ซีสามารถทำเช่นกันมี แต่ C ++ สามารถทำผ่านรูปแบบการออกแบบ Pimpl (ตัวชี้ทึบแสง)

ฉันบอกว่าจะบอกว่า C ++ มีสถานที่ในโลกฝังตัว คุณสามารถเกลียดทุกสิ่งที่คุณต้องการ แต่มันจะไม่หายไป มันสามารถเขียนได้อย่างมีประสิทธิภาพมาก แต่ก็ยากที่จะเรียนรู้วิธีการทำอย่างถูกต้องกว่ากับ C บางครั้งมันสามารถทำงานได้ดีกว่า C ในการแก้ปัญหาและบางครั้งก็แสดงอินเทอร์เฟซที่ดีกว่า ให้การศึกษาด้วยตนเองและไม่กลัวที่จะเรียนรู้วิธีการ

C ++ เหมาะสมอย่างยิ่งสำหรับระบบฝังตัว ตอนนี้ฉันใช้การมี / ไม่มีเครื่องมือการพัฒนาที่ดี (หรือขาดมัน) เป็นเกณฑ์หลักของฉันว่าจะใช้ไมโครโปรเซสเซอร์เฉพาะหรือไม่

พื้นที่ของ C ++ ที่ใช้งานได้ดีบนระบบฝังตัวเนื่องจากมีต้นทุนทรัพยากรต่ำ:

• modularity นำมาใช้ประโยชน์จากคลาส / โครงสร้าง
• แม่แบบถ้าคอมไพเลอร์ทำงานได้ดีในการรวบรวมอย่างมีประสิทธิภาพ เทมเพลตเป็นเครื่องมือที่ดีสำหรับการนำอัลกอริทึมกลับมาใช้ซ้ำกับชนิดข้อมูลต่างๆ

ตกลงพื้นที่:

• ฟังก์ชั่นเสมือน - ฉันเคยเป็นแบบนี้ แต่ค่าใช้จ่ายทรัพยากรมีขนาดเล็กมาก (หนึ่ง vtable ต่อคลาสไม่ใช่ต่อวัตถุหนึ่งตัวชี้ไปที่ vtable ต่อวัตถุหนึ่งการดำเนินการ dereferencing ต่อการเรียกใช้ฟังก์ชันเสมือน) และประโยชน์ที่ยิ่งใหญ่ของสิ่งนี้ คือมันช่วยให้คุณมีอาเรย์ที่มีออบเจกต์หลายประเภทที่ไม่มีการรู้ว่าพวกมันคืออะไร ฉันใช้สิ่งนี้เมื่อเร็ว ๆ นี้เพื่อให้มีอาร์เรย์ของวัตถุแต่ละชิ้นที่แสดงถึงอุปกรณ์ I2C ซึ่งแต่ละอันมีวิธีการแยกกัน

พื้นที่ที่ไม่ควรใช้ส่วนใหญ่เป็นเพราะค่าใช้จ่ายในการดำเนินการที่ไม่สามารถยอมรับได้ในระบบขนาดเล็ก:

• การจัดสรรหน่วยความจำแบบไดนามิก - อื่น ๆ ได้กล่าวถึงเรื่องนี้ แต่อีกเหตุผลสำคัญที่ไม่ควรใช้การจัดสรรหน่วยความจำแบบไดนามิกก็คือมันแสดงถึงความไม่แน่นอนในเวลา; เหตุผลหลายประการในการใช้ระบบฝังตัวสำหรับแอปพลิเคชันตามเวลาจริง
• RTTI (ข้อมูลชนิดรันไทม์) - ราคาหน่วยความจำค่อนข้างใหญ่
• ข้อยกเว้น - ไม่มีข้อ จำกัด ที่แน่นอนเนื่องจากความเร็วในการเรียกใช้งาน

ใช่ C ++ เหมาะสำหรับระบบฝังตัว ก่อนอื่นเรามาทำความเข้าใจกับความเข้าใจที่คลาดเคลื่อนเกี่ยวกับความแตกต่างระหว่าง C และ C ++:

ในไมโครที่มีการฝังตัวคุณจะต้องใช้ภาษาระดับสูงอย่างรอบคอบหากคุณกังวลเกี่ยวกับข้อ จำกัด ด้านเวลาหรือพื้นที่ ตัวอย่างเช่น MCUs จำนวนมากไม่จัดการพอยน์เตอร์ได้ดีและดังนั้นจึงไม่มีประสิทธิภาพมากเมื่อใช้สแต็ก ซึ่งหมายความว่าคุณต้องระวังเกี่ยวกับการส่งตัวแปรไปยังฟังก์ชั่นการใช้อาร์เรย์และพอยน์เตอร์และการเรียกซ้ำ เส้นเรียบง่ายของ C ชอบ:

a[i] = b[j] * c[k];

สามารถสร้างคำสั่งประมาณ 4 หน้าขึ้นอยู่กับลักษณะของตัวแปรเหล่านั้น

เมื่อใดก็ตามที่คุณใช้ใด ๆภาษาระดับสูงและคุณกังวลเกี่ยวกับเวลาและพื้นที่ที่ จำกัด แล้วคุณจำเป็นต้องรู้วิธีทุกคุณลักษณะของภาษาที่แปลเป็นคำแนะนำเกี่ยวกับเครื่อง MCU (อย่างน้อยคุณลักษณะที่คุณใช้ทุกครั้ง) สิ่งนี้เป็นจริงสำหรับ C, C ++, Ada อะไรก็ตาม ทุกภาษาน่าจะมีคุณสมบัติที่ไม่สามารถแปลได้อย่างมีประสิทธิภาพบน MCU ขนาดเล็ก ตรวจสอบรายการถอดแยกชิ้นส่วนทุกครั้งเพื่อให้แน่ใจว่าคอมไพเลอร์ไม่ได้สร้างรีมคำสั่งสำหรับสิ่งเล็กน้อย

C เหมาะสำหรับ MCU ที่ฝังตัวหรือไม่ ใช่ตราบใดที่คุณจับตาดูโค้ดที่สร้างขึ้น
C ++ เหมาะสำหรับ MCUs แบบฝังหรือไม่ ใช่ตราบใดที่คุณจับตาดูโค้ดที่สร้างขึ้น

นี่คือเหตุผลที่ฉันคิดว่า C ++ ดีกว่า C แม้ใน MCU 8 บิต: C ++ ให้การสนับสนุนที่ดีขึ้นสำหรับ:

• การซ่อนข้อมูล
• การพิมพ์ / ตรวจสอบที่แข็งแกร่งยิ่งขึ้น
• ความโปร่งใสหลายอุปกรณ์ต่อพ่วงโดยใช้คลาส
• เทมเพลต (เช่นเคยหากใช้อย่างระมัดระวัง)
• รายการเริ่มต้น
• const

คุณสมบัติเหล่านี้ไม่หนักกว่าคุณสมบัติทั่วไปของ C

ในขณะที่คุณย้าย MCUs มากถึง 16 หรือ 32 บิตจากนั้นจะเริ่มใช้งานคุณสมบัติที่หนักกว่าของ C (สแต็กกองพอยน์พอยน์เตอร์อาร์เรย์อาร์เรย์ printf และอื่น ๆ ) ในทางเดียวกัน MCU ที่ทรงพลังยิ่งเหมาะสม เพื่อใช้คุณสมบัติที่หนักกว่าของ C ++ (สแต็กกองการอ้างอิง STL ใหม่ / ลบ)

ดังนั้นไม่จำเป็นที่จะต้องตกใจเมื่อนึกถึง C ++ ใน PIC16 หากคุณรู้ภาษาและ MCU ของคุณอย่างถูกต้องคุณจะรู้วิธีการใช้ทั้งสองอย่างร่วมกันอย่างมีประสิทธิภาพ

ฉันมักจะพบการโต้วาทีเหล่านี้สนุกสนานอ่าน ไม่มากสำหรับการสนทนาทางปัญญาเกี่ยวกับข้อดีและข้อเสียของภาษาต่าง ๆ ที่มี แต่เพราะคุณสามารถตรึงท่าทางของใครบางคนในหัวข้อตามงาน / ประสบการณ์ / พื้นที่ที่น่าสนใจ มันอยู่ที่นั่นพร้อมกับข้อโต้แย้ง "การเพิ่มประสิทธิภาพก่อนวัยอันควร" คือสาขาวิชา CS และนักเขียนโปรแกรมบำรุงรักษาที่อ้างว่า Knuth ทางซ้ายและขวาและผู้ที่ทำงานในโลกแห่งความจริงที่ประสิทธิภาพการทำงานคิดว่าพวกเขาบ้าทั้งหมด (ฉันเป็นสมาชิกของกลุ่มหลัง เพื่อความยุติธรรม)

ในตอนท้ายของวันที่คุณสามารถพัฒนาซอฟต์แวร์ที่ดีใน C หรือ C ++ หรือแทรกภาษาที่นี่ มันมาพร้อมกับความสามารถของนักพัฒนาไม่ใช่ภาษา การเป็นผู้เชี่ยวชาญในภาษามักจะต้องใช้เฉพาะเมื่อคุณเลือกภาษาที่ไม่ถูกต้องเพื่อเริ่มต้นและตอนนี้จำเป็นต้องแปรปรวนในการแก้ปัญหาของคุณในกรณีส่วนใหญ่เหล่านี้เป็นสถานการณ์เดียวที่คุณจำเป็นต้องดำน้ำในลักษณะที่คลุมเครือหรือคอมไพเลอร์ เทคนิคเพื่อให้บรรลุเป้าหมาย

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

ฉันมักจะดูนักพัฒนาเลือกชุดเครื่องมือก่อนและพยายามที่จะโค้งงอกับปัญหาของพวกเขาที่สองซึ่งผิดอย่างสมบูรณ์และผลลัพธ์ในการแก้ปัญหาอึ

เมื่อฉันพูดถึงความคิดเห็นต่อคำตอบอื่นสงครามภาษาเหล่านี้มักจะตกอยู่ในการโต้เถียงว่าภาษา X อนุญาตให้โปรแกรมเมอร์ทำสิ่งที่โง่มากขึ้น ในขณะที่ให้ความบันเทิงในการอ่านข้อความเหล่านี้ทั้งหมดหมายถึงจริงๆว่าคุณมีปัญหาในการจ้างนักพัฒนาที่ดีและต้องจัดการกับปัญหานั้นโดยตรงแทนที่จะพยายามรวมกลุ่มเพื่อช่วยเหลือสถานการณ์โดยการจ้างนักพัฒนาที่ไม่ดีและเลือกเครื่องมือต่างๆ เสียหายมากที่สุด

ในความคิดของฉันนักพัฒนาที่ดีไม่ว่าจะเป็นการพัฒนาซอฟต์แวร์หรือฮาร์ดแวร์ค้นคว้าปัญหาออกแบบโซลูชันและค้นหาเครื่องมือที่ช่วยให้พวกเขาแสดงวิธีการแก้ปัญหาใน 'วิธีที่ดีที่สุด' ไม่สำคัญว่าเครื่องมือที่จำเป็นนั้นเป็นสิ่งที่คุณไม่เคยใช้มาก่อนหลังจากที่คุณใช้เครื่องมือ 3-4 ภาษา / การพัฒนาสำหรับโครงการที่รับใหม่ควรมีผลกระทบน้อยที่สุดต่อเวลาในการพัฒนาของคุณ

แน่นอนว่า 'วิธีที่ดีที่สุด' เป็นคำที่เป็นอัตวิสัยและจำเป็นต้องกำหนดในขั้นตอนการวิจัย เราจำเป็นต้องพิจารณาปัญหามากมาย: ประสิทธิภาพความง่ายในการแสดงออกความหนาแน่นของรหัส ฯลฯ ขึ้นอยู่กับปัญหาที่เกิดขึ้น ฉันไม่ได้รวมการบำรุงรักษาไว้ในรายการด้วยเหตุผลใดฉันไม่สนใจว่าคุณจะเลือกภาษาใดหากคุณเลือกเครื่องมือที่เหมาะสมและใช้เวลาในการทำความเข้าใจกับปัญหาที่เกิดขึ้นสิ่งนี้ควรจะเป็น 'ฟรี' ความยากในการบำรุงรักษาโค้ดมักเป็นผลมาจากการเลือกเครื่องมือที่ไม่ถูกต้องหรือโครงสร้างของระบบที่ไม่ดีส่งผลให้เกิดความยุ่งเหยิงแฮ็คที่น่าเกลียดเพื่อให้มันทำงานได้

การอ้างว่าภาษาใด ๆ นั้น 'ดีกว่า' อย่างใดอย่างหนึ่งนั้นโง่เกินไปโดยไม่ได้กำหนดปัญหาเฉพาะที่น่าสนใจ วิธีการเชิงวัตถุไม่ได้ดีไปกว่าวิธีการใช้งาน มีปัญหาบางอย่างที่ให้ยืมตัวเองได้ดีกับกระบวนทัศน์การออกแบบเชิงวัตถุ มีหลายอย่างที่ทำไม่ได้ ข้อความเดียวกันนี้สามารถสร้างขึ้นได้ด้วยคุณสมบัติหลายภาษาที่ผู้คนดูเหมือนจะเพลิดเพลินไปกับการเล่นพิณใหญ่

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

บ่อยครั้งที่ความจริงที่โชคร้ายคือธุรกิจจำนวนมากสามารถวัดมูลค่าของนักพัฒนาโดยจำนวนบรรทัดที่เขียนหรือโดยการดู 'ผลลัพธ์ที่จับต้องได้' พวกเขามอง 3 สัปดาห์ในห้องที่มีกระดานทำเครื่องหมายว่าเป็นการสูญเสียผลผลิต นักพัฒนามักถูกบังคับให้เร่งความเร็วผ่านขั้นตอน 'ความคิด' ของการพัฒนาหรือถูกบังคับให้ใช้เครื่องมือที่กำหนดโดยปัญหาทางการเมืองภายใน บริษัท "พี่ชายของเจ้านายของฉันทำงานกับ IBM เพื่อให้เราสามารถใช้เครื่องมือของพวกเขาได้" เท่านั้น . หรือแย่กว่านั้นคือคุณได้รับชุดข้อกำหนดที่เปลี่ยนแปลงตลอดเวลาจาก บริษัท เพราะพวกเขาไม่สามารถทำการวิจัยตลาดที่เหมาะสมหรือไม่เข้าใจถึงผลกระทบของการเปลี่ยนแปลงในวงจรการพัฒนา

ขออภัยที่ปิดหัวข้อเล็กน้อยด้วยอุบายนี้ฉันมีความคิดเห็นที่แข็งแกร่งในหัวข้อนี้

ภาษาใดก็ได้ที่เหมาะกับระบบฝังตัว สมองกลฝังตัวหมายถึง: ส่วนหนึ่งของอุปกรณ์ที่มีขนาดใหญ่กว่าเมื่อเทียบกับคอมพิวเตอร์ที่ใช้งานฟรี

คำถามที่มีความสัมพันธ์กันมากขึ้นเมื่อถาม(ยาก) เวลาจริงหรือจำกัด ทรัพยากรระบบ

สำหรับระบบเรียลไทม์ C ++ เป็นหนึ่งในภาษาสูงสุดที่ยังคงเหมาะสมเมื่อตั้งโปรแกรมสำหรับข้อ จำกัด ด้านเวลาที่เข้มงวด ด้วยข้อยกเว้นของการใช้ฮีป (โอเปอเรเตอร์ฟรี) มันไม่มีโครงสร้างที่มีเวลาดำเนินการที่ไม่แน่นอนดังนั้นคุณสามารถทดสอบได้ว่าโปรแกรมของคุณตอบสนองความต้องการด้านเวลาและมีประสบการณ์มากขึ้นคุณอาจคาดการณ์ได้ แน่นอนควรหลีกเลี่ยงการใช้ฮีปแม้ว่าผู้ปฏิบัติงานใหม่ยังสามารถใช้สำหรับการจัดสรรครั้งเดียวได้ โครงสร้างที่ C ++ นำเสนอเหนือ C สามารถนำไปใช้ประโยชน์ได้ดีในระบบฝังตัว: OO, ข้อยกเว้น, แม่แบบ

สำหรับระบบที่ จำกัด ทรัพยากร (ชิป 8 บิต, RAM น้อยกว่าไม่กี่, ไม่มีสแต็ก acessible) เต็ม C ++ อาจไม่เหมาะสมแม้ว่ามันอาจจะยังคงใช้เป็น 'ดีกว่า C'

ฉันคิดว่ามันน่าเสียดายที่ Ada นั้นดูเหมือนว่าจะใช้เฉพาะในบาง niches ในหลาย ๆ วิธีมันเป็น Pascal ++ แต่ไม่มีภาระในการเข้ากันได้กับภาษาที่เป็นระเบียบที่ร้ายแรงแล้วเริ่มต้นด้วย (แก้ไข: ความยุ่งเหยิงอย่างรุนแรงแน่นอน C Pascal เป็นภาษาที่สวยงาม แต่ใช้งานไม่ได้)

================================================== ==============

แก้ไข: ฉันกำลังพิมพ์คำตอบสำหรับคำถามใหม่ ("ในกรณีใดที่จำเป็นต้องใช้ภาษา C ++ เมื่อเราเขียนโปรแกรมไมโครคอนโทรลเลอร์"?) ที่ถูกปิดโดยอ้างถึงคำถามนี้ดังนั้นฉันจะเพิ่มสิ่งที่ฉันเขียนไว้:

ไม่เคยมีเหตุผลที่ครอบงำทั้งหมดสำหรับการใช้ภาษาการเขียนโปรแกรมใด ๆแต่อาจมีข้อโต้แย้งที่มีน้ำหนักมากหรือน้อยในสถานการณ์เฉพาะ การสนทนาเกี่ยวกับเรื่องนี้สามารถพบได้ในหลายสถานที่โดยตำแหน่งที่อยู่ในช่วงตั้งแต่ "ไม่เคยใช้ C ++ สำหรับไมโครคอนโทรลเลอร์" ถึง "มักจะใช้ C ++" ฉันมากขึ้นด้วยตำแหน่งสุดท้าย ฉันสามารถให้ข้อโต้แย้งบางอย่าง แต่คุณจะต้องตัดสินใจด้วยตัวเองว่าพวกเขามีน้ำหนักเท่าไรในสถานการณ์เฉพาะ (และในทิศทางใด)

• คอมไพเลอร์ C ++ นั้นหายากกว่าคอมไพเลอร์ C สำหรับเป้าหมายบางตัว (เช่น PIC หลัก 12 และ 14 บิต) ไม่มีคอมไพเลอร์ C ++ เลย
• (ดี) โปรแกรมเมอร์ C ++ นั้นหายากกว่า (ดี) โปรแกรมเมอร์ C โดยเฉพาะในกลุ่มที่มีความรู้ด้านอิเล็กทรอนิกส์
• C ++ มีโครงสร้างมากกว่า C ที่ไม่เหมาะสำหรับระบบขนาดเล็ก (เช่นข้อยกเว้น, RTTI, การใช้ฮีปบ่อยครั้ง)
• C ++ มีชุดของไลบรารี (มาตรฐาน) ที่สมบูรณ์ยิ่งขึ้นกว่า C แต่ผลลัพธ์ที่ได้จากจุดก่อนหน้าคือไลบรารี C ++ มักจะใช้คุณลักษณะที่ไม่เหมาะสมสำหรับระบบขนาดเล็กและดังนั้นจึงไม่ใช่เรื่องง่ายสำหรับระบบขนาดเล็ก
• C ++ มีโครงสร้างมากกว่า C ที่อนุญาตให้คุณยิงด้วยตัวเอง
• C ++ มีโครงสร้างมากกว่า C ที่อนุญาตให้คุณป้องกันไม่ให้คุณยิงตัวเองด้วยเท้า (ใช่ IMO อันนี้และอันก่อนหน้านี้เป็นจริงทั้งคู่)
• C ++ มีชุดของ abstraction ที่สมบูรณ์ยิ่งขึ้นดังนั้นมันจึงช่วยให้การเขียนโปรแกรมดีขึ้นโดยเฉพาะสำหรับไลบรารี
• คุณสมบัติภาษา C ++ (เช่นตัวสร้าง / destructors, ฟังก์ชั่นการแปลง) ทำให้ยากต่อการดูผ่านรหัสเพื่อดูเครื่องที่สร้างขึ้นและทำให้ค่าใช้จ่ายในพื้นที่และเวลาของการสร้างภาษา
• โครงสร้างภาษา C ++ ทำให้ไม่จำเป็นที่จะต้องตระหนักถึงความถูกต้องของการแปลเป็นรหัสเครื่องเพราะพวกเขาทำสิ่งที่ถูกต้องในทางที่เป็นนามธรรมมากขึ้น
• มาตรฐานภาษา C ++ มีการพัฒนาอย่างรวดเร็วและถูกนำไปใช้อย่างรวดเร็วโดยคอมไพเลอร์ขนาดใหญ่ (gcc, clang, microsoft) C มีการพัฒนาค่อนข้างโซเซและการใช้คุณสมบัติใหม่บางอย่าง (อาเรย์อาร์เรย์ที่แตกต่างกัน) นั้นทำให้ตกใจและได้ถูกย้อนกลับในมาตรฐานในภายหลัง โดยเฉพาะอย่างยิ่งประเด็นนี้น่าสนใจที่คนต่างใช้เพื่อสนับสนุนตำแหน่งตรงกันข้าม
• C ++ เป็นเครื่องมือที่คมชัดกว่า C อย่างไม่ต้องสงสัยคุณเชื่อใจโปรแกรมเมอร์ของคุณ (หรือตัวคุณเอง) ที่จะใช้เครื่องมือเพื่อสร้างรูปปั้นที่สวยงามหรือคุณกลัวว่ามันจะทำร้ายตัวเองและคุณค่อนข้างจะพอใจกับผลิตภัณฑ์ที่สวยงาม ? (ฉันจำได้ว่าครูประติมากรรมของฉันเคยบอกฉันว่าเครื่องมือทื่อสามารถในบางสถานการณ์อาจมีอันตรายมากกว่าคมชัด)

บล็อกของฉันมีงานเขียนบางส่วนเกี่ยวกับการใช้ C ++ ในระบบขนาดเล็ก (= ไมโครคอนโทรลเลอร์)

จากประสบการณ์ของฉัน C ++ มักไม่เหมาะกับระบบฝังตัวขนาดเล็ก โดยที่ฉันหมายถึงไมโครคอนโทรลเลอร์และอุปกรณ์ที่ไม่ใช้ระบบปฏิบัติการ

เทคนิค C ++ OOP จำนวนมากพึ่งพาการจัดสรรหน่วยความจำแบบไดนามิก สิ่งนี้มักจะหายไปในระบบขนาดเล็ก

STL และ Boost แสดงให้เห็นถึงพลังของ C ++ อย่างแท้จริงทั้งสองมีขนาดใหญ่มาก

C ++ สนับสนุนให้โปรแกรมเมอร์หยุดการทำงานของเครื่องในระบบที่มีข้อ จำกัด

เมื่อปีที่แล้วฉันได้ย้ายผลิตภัณฑ์เดสก์ท็อประยะไกลเชิงพาณิชย์ไปยังโทรศัพท์มือถือ มันเขียนใน C ++ และทำงานบน Windows, Linux และ OSX แต่มันอาศัยอย่างมากกับ STL, หน่วยความจำแบบไดนามิกและข้อยกเว้น C ++ เพื่อให้มันทำงานบน WinCE, Symbian และ OS-less environment การเขียน C เป็นตัวเลือกที่ปลอดภัยที่สุด

ฉันหวังว่าจะเพิ่มแสงสว่างมากกว่าความร้อนในการสนทนานี้เกี่ยวกับ C ++ บนโลหะเปลือยและระบบที่ จำกัด ทรัพยากร

ปัญหาใน C ++:

• ข้อยกเว้นเป็นปัญหา RAM โดยเฉพาะอย่างยิ่งในกรณีที่ "บัฟเฟอร์ฉุกเฉิน" ที่ต้องการ (ซึ่งข้อยกเว้นหน่วยความจำไม่เพียงพอ) อาจใหญ่กว่า RAM ที่มีอยู่และแน่นอนว่าจะเป็นการสิ้นเปลืองไมโครคอนโทรลเลอร์ สำหรับข้อมูลเพิ่มเติมโปรดดูที่n4049และn4234 พวกเขาควรจะปิด (ซึ่งเป็นพฤติกรรมที่ไม่ระบุในขณะนี้ดังนั้นโปรดตรวจสอบและไม่เคยโยน) SG14 กำลังทำงานกับวิธีที่ดีกว่าในการทำสิ่งนี้

• RTTI อาจไม่คุ้มกับค่าใช้จ่ายเลย แต่ควรปิด

• การสร้าง debug ขนาดใหญ่แม้ว่านี่ไม่ใช่ปัญหาในการพัฒนาเดสก์ท็อปแบบคลาสสิกถ้าการดีบักไม่พอดีกับชิปมันอาจเป็นปัญหา ปัญหาเกิดขึ้นจากรหัสเทมเพลตหรือการเรียกใช้ฟังก์ชันพิเศษที่เพิ่มเข้ามาเพื่อความชัดเจน การเรียกฟังก์ชั่นพิเศษเหล่านี้จะถูกลบออกอีกครั้งโดยเครื่องมือเพิ่มประสิทธิภาพและความคมชัดหรือความยืดหยุ่นที่เพิ่มเข้ามาอาจเป็นข้อได้เปรียบที่ยิ่งใหญ่อย่างไรก็ตามในการสร้างการดีบักอาจเป็นปัญหาได้

• การจัดสรรฮีป แม้ว่า STL จะอนุญาตให้ใช้ตัวจัดสรรแบบกำหนดเอง แต่สิ่งนี้อาจซับซ้อนสำหรับโปรแกรมเมอร์ส่วนใหญ่ การจัดสรรฮีปไม่ได้กำหนดไว้ล่วงหน้า (เช่นไม่ใช่เวลาจริงยาก) และการแตกแฟรกเมนต์อาจนำไปสู่สถานการณ์หน่วยความจำที่ไม่คาดคิดเกิดขึ้นแม้จะมีการทดสอบการทำงานอยู่ก็ตาม หนังสือที่ต้องการโดยกองเพื่อติดตามพื้นที่ว่างและขนาดแตกต่างกันอาจเป็นปัญหากับวัตถุขนาดเล็ก มันมักจะดีกว่าที่จะใช้การจัดสรรพูล (ทั้งใน C และ C ++) แต่สิ่งนี้อาจผิดปกติสำหรับโปรแกรมเมอร์ C ++ ที่ใช้ในการใช้ฮีปเท่านั้น

• ความแตกต่างแบบรันไทม์และการโทรทางอ้อมอื่น ๆ มักเป็นที่นิยมอย่างมากปัญหามักจะเกิดขึ้นเนื่องจากเครื่องมือเพิ่มประสิทธิภาพไม่สามารถมองเห็นพวกเขาได้มากกว่าการดึงข้อมูลและการกระโดดไปยังที่อยู่จริง หลีกเลี่ยงการโทรทางอ้อมด้วยเหตุผลนี้ใน C และ C ++ โดยที่ใน C ++ พวกเขาจะฝังลึกในวัฒนธรรม (และค่อนข้างมีประโยชน์ในโดเมนอื่น ๆ )

• การเชื่อมต่อโดยนัยกับ clib อาจเป็นปัญหาได้ อาจเป็นเรื่องที่เข้าใจง่ายว่าปัญหา clib อยู่ในหมวดหมู่ C ++ แต่ปัญหาเกิดจากการแบ่งปันทรัพยากรโดยปริยายในสภาพแวดล้อมที่เกิดขึ้นพร้อมกัน (การแบ่งปันนั้นชัดเจนมากขึ้นใน C) การใช้งานการดำเนินการ newLib ทั่วไปมักจะลากในจำนวนมากซึ่งไม่จำเป็นต้องใช้ในยูซีเอสในทางตรงกันข้าม newLibNanno ไม่ได้เป็น reentrant ดังนั้นการเข้าถึงจะต้องต่อเนื่องกัน (การขยายที่นี่) นี่เป็นปัญหาสำหรับ C เช่นกัน แต่การเข้าถึงนั้นชัดเจนยิ่งขึ้น ตามกฎของหัวแม่มือเราไม่ควรใช้อะไรจาก namespace std ในบริบท ISR ถ้าคุณแน่ใจว่ามันไม่สามารถเข้าถึงสถานะใน clib ได้ (errorno หรือ heap เป็นต้น) นอกจากนี้ยังมีความสำคัญหากคุณใช้เธรด (ฉันชอบ RTC) เพื่อแทนที่ใหม่และลบเพื่อซิงโครไนซ์การเข้าถึง malloc และฟรี

โดยสรุป C ++ มีปัญหาบางอย่าง แต่พวกมันสามารถแก้ไขได้หรือหลีกเลี่ยงได้

ตอนนี้สำหรับ C นี่คือปัญหาคือการสั่งซื้อที่สูงขึ้น ฉันไม่มีความสามารถในการสร้างประโยค C ในสิ่งที่เป็นนามธรรมในวิธีที่ฉันสามารถดำเนินการปรับให้เหมาะสมหรือตรวจสอบค่าคงที่ในเวลารวบรวม ดังนั้นฉันจึงไม่สามารถห่อหุ้มสิ่งต่าง ๆ ในแบบที่ผู้ใช้ไม่จำเป็นต้องรู้ว่าพวกเขาทำงานอย่างไรเพื่อที่จะใช้พวกเขาและการตรวจจับข้อผิดพลาดส่วนใหญ่ของฉันจะทำที่รันไทม์ (ซึ่งไม่เพียง แต่สายเกินไป โดยพื้นฐานแล้ววิธีเดียวที่จะเป็นทั่วไปใน C คือผ่านข้อมูลฉันส่งสตริงรูปแบบไปยัง printf หรือ scanf ซึ่งประเมินที่รันไทม์เช่น มันค่อนข้างยากสำหรับคอมไพเลอร์ที่จะพิสูจน์ว่าฉันไม่ได้ใช้ตัวเลือกบางอย่างที่เป็นไปได้ในทางทฤษฎีเมื่อส่งผ่านข้อมูลที่ถูกต้องซึ่งหมายถึงการสร้างรหัสตายที่อาจเกิดขึ้นและสูญเสียศักยภาพในการเพิ่มประสิทธิภาพ

ฉันรู้ว่าฉันอาจจะปลดปล่อย shitstorm ที่นี่ แต่ประสบการณ์ของฉันในไมโครคอนโทรลเลอร์ขนาด 32 บิตคือในแอปเปิ้ลกับแอปเปิ้ลเปรียบเทียบของ C และ C ++ ทั้งที่เขียนโดยผู้เชี่ยวชาญ สิ่งใดก็ตามที่จำเป็นต้องมีในลักษณะทั่วไป (เช่นในห้องสมุดใด ๆ ) และพวกมันมีความเท่าเทียมกันในกรณีทั่วไป นอกจากนี้ยังง่ายสำหรับผู้เริ่มใช้ประโยชน์จากความเชี่ยวชาญของผู้ดำเนินการไลบรารี่ผู้เชี่ยวชาญใน C ++

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

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

ในสิ่ง C ++ สามารถ encapsulated โดยผู้เชี่ยวชาญและใช้ในสภาพแวดล้อมหลาย ๆ ที่การสร้างรหัสเวลารวบรวมปรับให้เหมาะกับงานที่เฉพาะเจาะจงและการตรวจสอบแบบคงที่ช่วยให้ผู้ใช้จากการทำสิ่งที่โง่ที่ศูนย์ค่าใช้จ่าย ที่นี่เรามีการแลกเปลี่ยนน้อยลงระหว่างการเป็นคนทั่วไปและรวดเร็วและในที่สุดจากต้นทุนกับมุมมองประโยชน์เป็นภาษาที่มีประสิทธิภาพปลอดภัยและมีประสิทธิผลมากขึ้น

มันเป็นคำวิจารณ์ที่ถูกต้องว่ายังมีปัญหาการขาดแคลนไลบรารี C ++ ที่ดีสำหรับการฝังซึ่งอาจนำไปสู่การตัดสินใจเชิงปฏิบัติเพื่อใช้ C เป็นส่วนใหญ่ในคอมไพเลอร์ C ++ การตัดสินใจใช้ C เพียงอย่างเดียวในโครงการโดยพื้นฐานแล้วเป็นการขับเคลื่อนในเชิงอุดมการณ์ไม่จำเป็นต้องได้รับการสนับสนุนแบบดั้งเดิมหรือการยอมรับว่าทีมไม่ได้รับการลงโทษทางวินัยมากพอที่จะละเว้นจากชุดที่โง่ ๆ ที่เลือกได้ใน C ++ แต่ไม่ใช่ C และในเวลาเดียวกันก็มีระเบียบวินัยมากพอที่จะไม่ทำสิ่งโง่ ๆ ที่ยิ่งใหญ่ซึ่งไม่สามารถป้องกันใน C แต่ทำได้ใน C ++

พื้นหลังของฉัน: เพิ่งออกจากการฝึกอบรมโรงเรียนภายใต้โปรแกรมเมอร์ Bell Labs เก่า; ทำงานเป็นเวลา 3 ปี 2 ในโครงการวิจัยระดับปริญญาตรี การเก็บข้อมูล / การควบคุมกระบวนการใน VB.NET ใช้เวลา 1.5 ปีในการทำงานกับแอพพลิเคชันฐานข้อมูลองค์กรใน VB6 ปัจจุบันทำงานในโครงการสำหรับพีซีแบบฝังที่มีหน่วยความจำ 2GB, RAM 512MB, 500MHz x86 CPU; มีหลายแอพที่ใช้งานเขียนใน C ++ พร้อมกับกลไก IPC ใช่ฉันยังเด็ก

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

• C ++ นั้นแตกต่างจาก C ( พื้นฐานคือไม่มี C / C ++) ในขณะที่ทุกอย่างที่ถูกต้อง C คือ C ++ ที่ถูกต้อง แต่ C ++ เป็นภาษาที่แตกต่างกันมากและเราจำเป็นต้องเรียนรู้วิธีการเขียนโปรแกรมใน C ++ ไม่ใช่ C เพื่อใช้งานได้อย่างมีประสิทธิภาพในทุกสถานการณ์ ใน C ++ คุณต้องเขียนโปรแกรมเชิงวัตถุไม่ใช่แบบขั้นตอนและไม่ใช่แบบไฮบริดของทั้งสอง (คลาสขนาดใหญ่ที่มีฟังก์ชั่นมากมาย) โดยทั่วไปคุณควรมุ่งเน้นการสร้างชั้นเรียนขนาดเล็กที่มีฟังก์ชั่นน้อยและประกอบชั้นเรียนขนาดเล็กทั้งหมดเข้าด้วยกันเป็นโซลูชันที่ใหญ่ขึ้น เพื่อนร่วมงานคนหนึ่งของฉันอธิบายกับฉันว่าฉันเคยเขียนโปรแกรมเกี่ยวกับวัตถุซึ่งเป็นระเบียบที่ยิ่งใหญ่และยากต่อการบำรุงรักษา เมื่อฉันเริ่มใช้เทคนิคเชิงวัตถุเพิ่มเติมฉันพบว่าโค้ดบำรุงรักษา / ความสามารถในการอ่านของฉันเพิ่มขึ้น

• C ++ มีคุณสมบัติเพิ่มเติมในรูปแบบของการพัฒนาเชิงวัตถุที่สามารถให้วิธีที่จะลดความซับซ้อนของรหัสเพื่อให้ง่ายต่อการอ่าน / รักษา สุจริตฉันไม่คิดว่าจะมีวิธีการปรับปรุงประสิทธิภาพ / พื้นที่ในการทำ OOP แต่ฉันคิดว่า OOP เป็นเทคนิคที่สามารถช่วยแบ่งปัญหาที่ซับซ้อนออกเป็นชิ้นเล็ก ๆ ได้ และเป็นประโยชน์สำหรับผู้ที่ทำงานกับรหัสซึ่งเป็นองค์ประกอบของกระบวนการนี้ที่ไม่ควรเพิกเฉย

• อาร์กิวเมนต์หลายตัวที่มีต่อ C ++ นั้นเกี่ยวเนื่องกับการจัดสรรหน่วยความจำแบบไดนามิกเป็นหลัก C มีปัญหาเดียวกันนี้ด้วย คุณสามารถเขียนแอปพลิเคชันเชิงวัตถุโดยไม่ต้องใช้หน่วยความจำแบบไดนามิกแม้ว่าหนึ่งในข้อดีของการใช้วัตถุคือคุณสามารถจัดสรรสิ่งเหล่านี้แบบไดนามิกในแบบง่าย ๆ เช่นเดียวกับใน C คุณต้องระมัดระวังเกี่ยวกับวิธีการจัดการข้อมูลเพื่อลดการรั่วไหลของหน่วยความจำ แต่เทคนิค RAIIทำให้สิ่งนี้ง่ายขึ้นใน C ++ (ทำให้การทำลายหน่วยความจำแบบไดนามิกโดยอัตโนมัติโดยการห่อหุ้มในวัตถุ) ในบางแอพพลิเคชั่นซึ่งทุกตำแหน่งของหน่วยความจำมีความสำคัญ

แก้ไข:

• WRT คำถาม "Arduino C ++" : ฉันขอยืนยันว่า C ++ ที่ไม่มีการจัดการหน่วยความจำแบบไดนามิกยังคงมีประโยชน์ คุณสามารถจัดระเบียบรหัสของคุณลงในวัตถุแล้ววางวัตถุเหล่านั้นลงในตำแหน่งที่ตั้งต่าง ๆ ภายในแอปพลิเคชันของคุณตั้งค่าอินเทอร์เฟซการติดต่อกลับ ฯลฯ ตอนนี้ฉันได้พัฒนาใน C ++ ฉันสามารถเห็นหลายวิธีที่แอปพลิเคชัน สแต็กยังคงมีประโยชน์กับวัตถุ ฉันจะยอมรับว่า - ฉันไม่เคยเขียนแอพแบบฝังตัวเช่นนั้นสำหรับ Arduino ดังนั้นฉันจึงไม่มีข้อพิสูจน์เบื้องหลังการอ้างสิทธิ์ของฉัน ฉันมีโอกาสที่จะพัฒนา Arduino ในโครงการที่กำลังจะมาถึง - หวังว่าฉันจะสามารถทดสอบการอ้างสิทธิ์ของฉันได้ที่นั่น

ใช่ปัญหาเกี่ยวกับ C ++ คือส่วนเสริมที่เพิ่มขึ้นของรหัส

ในบางระบบคุณกำลังนับไบต์และในกรณีนั้นคุณจะต้องยอมรับค่าใช้จ่ายในการใช้งานที่ใกล้เคียงกับขอบเขตของระบบของคุณคือต้นทุนการพัฒนาที่สูงขึ้นของ C

แต่ถึงแม้จะอยู่ใน C สำหรับระบบที่ได้รับการออกแบบมาอย่างดีคุณจะต้องเก็บทุกสิ่งไว้ในห่อหุ้ม ระบบที่ได้รับการออกแบบมาอย่างดีนั้นยากและ C ++ ให้โปรแกรมเมอร์เป็นสถานที่สำหรับวิธีการพัฒนาและควบคุมอย่างเป็นระบบ มีค่าใช้จ่ายในการเรียนรู้ OOP และหากคุณต้องการเปลี่ยนไปใช้คุณยอมรับมันมากและในหลาย ๆ กรณีฝ่ายบริหารค่อนข้างดำเนินการต่อกับ C และไม่จ่ายค่าใช้จ่ายเนื่องจากเป็นการยากที่จะวัดผลลัพธ์ของสวิตช์ที่ เพิ่มผลผลิต คุณสามารถดูบทความโดยระบบฝังตัวกูรูแจ็ค Ganssle ที่นี่

การจัดการหน่วยความจำแบบไดนามิกเป็นปีศาจ ไม่จริงมารเป็นเส้นทางอัตโนมัติการจัดการหน่วยความจำแบบไดนามิกใช้งานได้ดีบนพีซี แต่คุณสามารถคาดหวังว่าจะรีสตาร์ทพีซีทุกสองสามสัปดาห์เป็นอย่างน้อย คุณจะพบว่าในขณะที่ระบบสมองกลฝังตัวยังคงทำงานต่อเนื่องเป็นเวลา 5 ปีการจัดการหน่วยความจำแบบไดนามิกสามารถทำให้พลาดและเริ่มล้มเหลวได้Ganssle พูดถึงสิ่งต่าง ๆ เช่นกองซ้อนและกองในบทความของเขา

มีบางสิ่งใน C ++ ที่มีแนวโน้มที่จะก่อให้เกิดปัญหาและใช้ทรัพยากรมากมายการลบการจัดการหน่วยความจำแบบไดนามิกและเทมเพลตเป็นขั้นตอนใหญ่เพื่อให้ footprint ของ C ++ ใกล้กับ footprint ของ C นี่ยังคงเป็น C ++ คุณไม่จำเป็นต้องใช้ไดนามิก การจัดการหน่วยความจำหรือแม่แบบในการเขียน C ++ ที่ดี ฉันไม่ได้ตระหนักถึงพวกเขาลบข้อยกเว้นฉันพิจารณาข้อยกเว้นเป็นส่วนสำคัญของรหัสที่ฉันลบในรุ่น แต่ใช้จนกว่าจะถึงจุดนั้น ในการทดสอบภาคสนามฉันสามารถมีข้อยกเว้นสร้างข้อความเพื่อแจ้งให้ฉันทราบถึงข้อยกเว้นที่ถูกจับได้

ฉันคิดว่าคำปรามาสต่อต้าน C ++ นี้โดย Linus Torvalds น่าสนใจ

หนึ่งในคุณสมบัติที่เลวร้ายที่สุดอย่างแน่นอนของ C ++ คือวิธีที่ทำให้สิ่งต่างๆมากมายขึ้นอยู่กับบริบท - ซึ่งหมายความว่าเมื่อคุณดูโค้ดมุมมองภายในเครื่องจะไม่ค่อยให้บริบทเพียงพอที่จะรู้ว่าเกิดอะไรขึ้น

เขาไม่ได้พูดถึงโลกของระบบฝังตัว แต่เป็นการพัฒนาเคอร์เนลของ Linux สำหรับฉันแล้วความเกี่ยวข้องมาจากสิ่งนี้: C ++ ต้องเข้าใจบริบทที่กว้างขึ้นและฉันสามารถเรียนรู้การใช้ชุดแม่แบบวัตถุฉันไม่เชื่อว่าตัวเองจะจำพวกเขาเมื่อฉันต้องปรับปรุงรหัสในอีกไม่กี่เดือน

(ในทางกลับกันฉันกำลังทำงานกับอุปกรณ์ฝังตัวโดยใช้ Python (ไม่ใช่ C ++ แต่ใช้ OOP กระบวนทัศน์เดียวกัน) ที่จะมีปัญหาตรงนั้นในการป้องกันของฉันมันเป็นระบบฝังตัวที่ทรงพลังพอที่จะเรียกพีซี 10 ปีที่แล้ว.)

ฉันคิดว่าคำตอบอื่น ๆ ทำให้เป็นกรณีที่ดีมากสำหรับข้อดีข้อเสียและปัจจัยในการตัดสินใจดังนั้นฉันจึงต้องการสรุปและเพิ่มความคิดเห็นเล็กน้อย

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

สำหรับไมโครคอนโทรลเลอร์ระดับไฮเอนด์ (เช่น 32- บิต, 10s หรือ 100s ของ MB สำหรับ RAM และที่เก็บข้อมูล) ที่มีระบบปฏิบัติการที่เหมาะสมมันใช้ได้ดีและฉันก็กล้าที่จะบอกด้วย

ดังนั้นคำถามคือขอบเขตของที่ไหน

ฉันไม่รู้แน่ชัด แต่เมื่อฉันพัฒนาระบบสำหรับ uC แบบ 16 บิตพร้อม RAM 1 MB และที่เก็บข้อมูล 1 MB ใน C ++ เพียงเพื่อเสียใจในภายหลัง ใช่มันใช้งานได้ แต่งานพิเศษที่ฉันมีไม่คุ้ม ฉันต้องทำให้มันพอดีตรวจสอบให้แน่ใจว่าสิ่งต่าง ๆ เช่นข้อยกเว้นจะไม่ทำให้เกิดการรั่วไหล (การสนับสนุน OS + RTL นั้นค่อนข้างน่าเชื่อถือและไม่น่าเชื่อถือ) ยิ่งไปกว่านั้นแอพ OO จะทำการจัดสรรขนาดเล็กจำนวนมากและค่าใช้จ่ายสำหรับฮีปนั้นเป็นฝันร้ายอีกอัน

จากประสบการณ์นั้นฉันจะสมมติว่าโครงการในอนาคตที่ฉันจะเลือก C ++ เฉพาะในระบบอย่างน้อย 16 บิตและอย่างน้อย 16 MB สำหรับ RAM และที่เก็บข้อมูล นั่นเป็นข้อ จำกัด โดยพลการและอาจแตกต่างกันไปตามสิ่งต่าง ๆ เช่นประเภทของแอปพลิเคชั่นรูปแบบการเข้ารหัสและสำนวน ฯลฯ แต่ด้วยข้อแม้ฉันขอแนะนำวิธีการที่คล้ายกัน

มีคุณสมบัติบางอย่างของ C ++ ที่มีประโยชน์ในระบบฝังตัว มีคนอื่นเช่นข้อยกเว้นซึ่งอาจมีราคาแพงและค่าใช้จ่ายที่อาจไม่ชัดเจน

ถ้าฉันมีคนชำนาญการจะมีภาษายอดนิยมที่รวมสิ่งที่ดีที่สุดของทั้งสองโลกเข้าด้วยกันและรวมคุณสมบัติบางอย่างที่ขาดทั้งสองภาษาไว้ด้วยกัน ผู้ขายบางรายมีคุณสมบัติดังกล่าวเล็กน้อย แต่ไม่มีมาตรฐาน บางสิ่งที่ฉันต้องการดู:

1. การจัดการข้อยกเว้นเล็ก ๆ น้อย ๆ เช่น Java ซึ่งฟังก์ชันที่สามารถโยนหรือรั่วไหลข้อยกเว้นจะต้องประกาศเช่นนี้ ในขณะที่ความต้องการสำหรับการประกาศดังกล่าวอาจค่อนข้างน่ารำคาญจากมุมมองการเขียนโปรแกรมมันจะปรับปรุงความชัดเจนของรหัสในกรณีที่ฟังก์ชั่นอาจกลับจำนวนเต็มโดยพลการถ้ามันประสบความสำเร็จ แต่อาจล้มเหลว แพลตฟอร์มจำนวนมากสามารถจัดการกับโค้ดราคาไม่แพงเช่นการมีค่าตอบแทนในการลงทะเบียนและการบ่งชี้ความสำเร็จ / ความล้มเหลวในการตั้งค่าสถานะการพกพา
2. โอเวอร์โหลดของฟังก์ชั่นคงที่และแบบอินไลน์เท่านั้น ความเข้าใจของฉันคือว่าหน่วยงานมาตรฐานสำหรับ C ได้หลีกเลี่ยงการทำงานหนักเกินไปเพื่อหลีกเลี่ยงความจำเป็นในการจัดการชื่อ การอนุญาตให้โอเวอร์โหลดของฟังก์ชันสแตติกและอินไลน์เท่านั้นจะหลีกเลี่ยงปัญหานั้นและจะให้ประโยชน์ 99.9% ของการโอเวอร์โหลดฟังก์ชั่นภายนอก (เนื่องจากไฟล์. h สามารถกำหนดอินไลน์โอเวอร์โหลดในแง่ของฟังก์ชั่นภายนอกที่มีชื่อต่างกัน)
3. โอเวอร์โหลดสำหรับค่าพารามิเตอร์คงที่โดยพลการหรือเวลาเฉพาะที่แก้ไขได้ ฟังก์ชั่นบางอย่างอาจอินไลน์อย่างมีประสิทธิภาพมากเมื่อผ่านกับค่าคงที่ใด ๆ แต่อินไลน์แย่มากถ้าผ่านตัวแปร รหัสเวลาอื่น ๆ ซึ่งอาจเป็นการปรับให้เหมาะสมถ้าค่าคงที่อาจเป็นการมองในแง่ร้ายหากไม่เป็นเช่นนั้น ตัวอย่างเช่น:

   inline ถือเป็นโมฆะ copy_uint32s (uint32_t * ปลายทาง, const uint32_t * src, __is_const int n)
   {
     ถ้า (n <= 0) กลับมา;
     อื่นถ้า (n == 1) {dest [0] = src [0];}
     อื่นถ้า (n == 2) {dest [0] = src [0]; ปลายทาง [1] = src [1];}
     อื่นถ้า (n == 3) {dest [0] = src [0]; ปลายทาง [1] = src [1]; ปลายทาง [2] = src [2];}
     อื่นถ้า (n == 4) {ปลายทาง [0] = src [0]; ปลายทาง [1] = src [1]; ปลายทาง [2] = src [2]; ปลายทาง [3] = src [3];}
     else memcpy ((เป็นโมฆะ *) ปลายทาง, (โมฆะ const *) src, n * sizeof (* src));
   }
   

   หากสามารถประเมิน 'n' ในเวลาคอมไพล์โค้ดด้านบนจะมีประสิทธิภาพมากกว่าการเรียกไปยัง memcpy แต่ถ้า 'n' ไม่สามารถประเมินได้ในเวลาคอมไพล์รหัสที่สร้างขึ้นจะใหญ่กว่าและช้ากว่าโค้ดที่เรียบง่ายมาก เรียกว่า memcpy

ฉันรู้ว่าพ่อของ C ++ ไม่กระตือรือร้นกับ C ++ รุ่นฝังตัวเพียงอย่างเดียว แต่ฉันคิดว่ามันจะมีการปรับปรุงที่สำคัญมากกว่าการใช้ C เท่านั้น

ใครบ้างที่รู้ว่าสิ่งใดที่กล่าวมาข้างต้นกำลังได้รับการพิจารณาสำหรับมาตรฐานประเภทใด?

C ++ เป็นมากกว่าหนึ่งภาษาการเขียนโปรแกรม:

a) มันเป็น "ดีกว่า" C b) มันเป็นภาษาเชิงวัตถุ c) มันเป็นภาษาที่ช่วยให้เราสามารถเขียนโปรแกรมทั่วไป

แม้ว่าคุณสมบัติทั้งหมดเหล่านี้สามารถใช้แยกกันได้ แต่ผลลัพธ์ที่ดีที่สุดจะเกิดขึ้นได้เมื่อใช้สามคุณสมบัติพร้อมกัน อย่างไรก็ตามหากคุณเลือกที่จะเลือกหนึ่งในนั้นคุณภาพของซอฟต์แวร์ฝังตัวจะเพิ่มขึ้น

a) มันเป็น "ดีกว่า" ค

C ++ เป็นภาษาที่พิมพ์ได้ดี แข็งแกร่งกว่า C. โปรแกรมของคุณจะได้รับประโยชน์จากคุณสมบัตินี้

บางคนกลัวพอยน์เตอร์ C ++ รวมถึงการอ้างอิง ฟังก์ชั่นโอเวอร์โหลด

และคุ้มค่าที่จะพูด: ไม่มีคุณสมบัติเหล่านี้เกิดขึ้นในโปรแกรมที่ใหญ่กว่าหรือช้ากว่า

b) เป็นภาษาเชิงวัตถุ

มีคนพูดในโพสต์นี้ว่าการทำให้เครื่องในไมโครคอนโทรลเลอร์เป็นไปไม่ได้เป็นความคิดที่ดี ไม่ถูกต้อง! พวกเราทุกคนวิศวกรที่ฝังตัวได้แยกเครื่องเสมอโดยเฉพาะกับ sintax อื่น ๆ ที่ C ++ ปัญหาที่ฉันเห็นด้วยอาร์กิวเมนต์นี้คือโปรแกรมเมอร์บางคนไม่ได้ใช้ในการคิดในวัตถุนั่นคือวิธีที่พวกเขาไม่เห็นประโยชน์ของ OOP

เมื่อใดก็ตามที่คุณพร้อมที่จะใช้อุปกรณ์ต่อพ่วงของไมโครคอนโทรลเลอร์มันอาจเป็นไปได้ว่าอุปกรณ์ต่อพ่วงได้ถูกทำให้เป็นนามธรรมสำหรับเรา (จากตัวคุณเองหรือบุคคลที่สาม) ในรูปแบบของไดรเวอร์อุปกรณ์ อย่างที่ฉันพูดไว้ก่อนหน้านี้ไดรเวอร์นั้นใช้ C sintax ดังตัวอย่างต่อไปนี้แสดง (นำมาโดยตรงจากตัวอย่าง NXP LPC1114):

/ * การตั้งค่าตัวจับเวลาสำหรับการจับคู่และขัดจังหวะที่ TICKRATE_HZ * /

Chip_TIMER_Reset (LPC_TIMER32_0);

Chip_TIMER_MatchEnableInt (LPC_TIMER32_0, 1);

Chip_TIMER_SetMatch (LPC_TIMER32_0, 1, (timerFreq / TICKRATE_HZ2));

Chip_TIMER_ResetOnMatchEnable (LPC_TIMER32_0, 1);

Chip_TIMER_Enable (LPC_TIMER32_0);

คุณเห็นสิ่งที่เป็นนามธรรมหรือไม่? ดังนั้นเมื่อใช้ C ++ เพื่อจุดประสงค์เดียวกัน Abstraction จะถูกนำไปสู่อีกระดับผ่านกลไก Abstraction และ Encapsulation ของ C ++ ในราคาศูนย์!

c) เป็นภาษาที่ช่วยให้เราสามารถเขียนโปรแกรมทั่วไป

โปรแกรมทั่วไปสามารถทำได้ผ่านแม่แบบและแม่แบบนั้นไม่มีค่าใช้จ่ายสำหรับโปรแกรมของเรา

นอกจากนี้รูปแบบคงที่จะประสบความสำเร็จกับแม่แบบ

วิธีเสมือน RTTI และข้อยกเว้น

มีการประนีประนอมเมื่อใช้วิธีการเสมือน: ซอฟต์แวร์ที่ดีกว่าและโทษในประสิทธิภาพ อย่างไรก็ตามโปรดจำไว้ว่าการเชื่อมโยงแบบไดนามิกมีแนวโน้มที่จะนำมาใช้โดยใช้ตารางเสมือน (อาเรย์ของตัวชี้ฟังก์ชัน) ฉันทำแบบเดียวกันใน C หลายครั้ง (แม้เป็นประจำ) ดังนั้นฉันจึงไม่เห็นข้อเสียในการใช้วิธีการเสมือน ยิ่งไปกว่านั้นวิธีการเสมือนใน C ++ นั้นสง่างามยิ่งกว่า

ในที่สุดคำแนะนำเกี่ยวกับ RTTI และข้อยกเว้น: อย่าใช้พวกเขาในระบบฝังตัว หลีกเลี่ยงค่าใช้จ่ายทั้งหมด !!

พื้นหลังของฉันฝังตัว (mcu, pc, unix, อื่น ๆ ) เรียลไทม์ ความปลอดภัยที่สำคัญ ฉันแนะนำนายจ้างก่อนหน้านี้ให้ STL ฉันไม่ทำเช่นนั้นอีกแล้ว

เนื้อหา Flame บางอย่าง

C ++ เหมาะสำหรับระบบฝังตัวหรือไม่

Meh C ++ เป็นความเจ็บปวดที่จะเขียนและความเจ็บปวดในการรักษา C + ไม่เป็นไร (ไม่ใช้คุณสมบัติบางอย่าง)

C ++ ในไมโครคอนโทรลเลอร์? RTOSes? เครื่องปิ้งขนมปัง? พีซีแบบฝัง?

อีกครั้งฉันพูดว่า Meh C + ไม่ได้เลวร้ายเกินไป แต่ ADA นั้นเจ็บปวดน้อยกว่า หากคุณโชคดีอย่างฉันคุณต้องทำจาวาฝัง การตรวจสอบการเข้าถึงอาร์เรย์และไม่มีตัวชี้ทางคณิตศาสตร์ทำให้รหัสที่เชื่อถือได้มาก ตัวรวบรวมขยะใน Java ที่ฝังตัวนั้นไม่ได้มีความสำคัญสูงสุดและมีหน่วยความจำที่กำหนดขอบเขตและการนำวัตถุกลับมาใช้ใหม่ดังนั้นโค้ดที่ออกแบบมาอย่างดีสามารถทำงานได้ตลอดไปโดยไม่มี GC

OOP มีประโยชน์กับไมโครคอนโทรลเลอร์หรือไม่

แน่นอนว่าเป็น UART เป็นวัตถุ ..... DMAC เป็นวัตถุ ...

เครื่อง Object State นั้นง่ายมาก

C ++ ลบโปรแกรมเมอร์ที่อยู่ห่างจากฮาร์ดแวร์มากเกินไปหรือไม่

นอกจากจะเป็น PDP-11 แล้ว C ไม่ใช่ซีพียูของคุณ C ++ เดิมทีเป็นตัวประมวลผลล่วงหน้าบน C ดังนั้น Bjarne Stroustrup จะหยุดหัวเราะเพราะการจำลอง Simula ช้าในขณะที่ AT&T C ++ ไม่ใช่ซีพียูของคุณ

ไปรับ MCU ที่รันจาวาโค้ด โปรแกรมใน Java หัวเราะเยาะพวก C

C ++ ของ Arduino ควร (ที่ไม่มีการจัดการหน่วยความจำแบบไดนามิก, แม่แบบ, ข้อยกเว้น) ควรได้รับการพิจารณาว่าเป็น "C ++ จริง" หรือไม่?

Nope เหมือนกับคอมไพเลอร์ C ที่ถูกกลั่นแกล้งออกมาเพื่อ MCU

Forth, Embedded Java หรือ Embedded ADA นั้นเป็นมาตรฐาน (ish); ทั้งหมดคือความเศร้าโศก

ระบบสมองกลฝังตัวได้รับการออกแบบมาเพื่อทำงานบางอย่างแทนที่จะเป็นคอมพิวเตอร์อเนกประสงค์สำหรับงานหลายงาน ระบบฝังตัวคือการรวมกันของฮาร์ดแวร์คอมพิวเตอร์และซอฟต์แวร์ C เป็นแม่ของภาษาสมัยใหม่ทั้งหมด มันอยู่ในระดับต่ำ แต่เต็มไปด้วยพลังภาษาและข้อเสนอของฮาร์ดแวร์ทุกชนิด ดังนั้น C / C ++ จึงเป็นตัวเลือกที่ดีที่สุดสำหรับการพัฒนาซอฟต์แวร์สำหรับระบบฝังตัวซึ่งมีการใช้งานอย่างเต็มรูปแบบสำหรับทุกระบบที่ฝังอยู่เรารู้ว่า C เป็นภาษาที่กำลังพัฒนา ระบบปฏิบัติการ UNIX เขียนด้วยภาษา C เนื่องจากการพัฒนาซอฟต์แวร์ที่ประสบความสำเร็จนั้นบ่อยครั้งมากเกี่ยวกับการเลือกภาษาที่ดีที่สุดสำหรับโครงการที่กำหนดจึงน่าแปลกใจที่พบว่าภาษา C / C ++ ได้พิสูจน์ตัวเองแล้วว่าเหมาะสมสำหรับโปรเซสเซอร์ 8 บิตและ 64 บิต ; ในระบบที่มีหน่วยเป็นไบต์, กิโลไบต์และหน่วยความจำเมกะไบต์ C มีข้อได้เปรียบในการประมวลผลอิสระ ซึ่งอนุญาตให้โปรแกรมเมอร์ให้ความสนใจกับอัลกอริธึมและแอปพลิเคชันมากกว่ารายละเอียดของสถาปัตยกรรมตัวประมวลผลเฉพาะ อย่างไรก็ตามข้อดีเหล่านี้มีประโยชน์มากมายกับภาษาระดับสูงอื่น ๆ แต่ C / C ++ ประสบความสำเร็จในที่ที่ภาษาอื่น ๆ มากมายล้มเหลวอย่างมาก

<พูดจาโผงผาง>

ฉันคิดว่า C ++ เป็นภาษาเส็งเคร็งตั้งแต่แรก หากคุณต้องการใช้ OOP ให้เขียนโปรแกรม Java C ++ ไม่ทำอะไรเลยในการบังคับใช้กระบวนทัศน์ OOP เนื่องจากการเข้าถึงหน่วยความจำโดยตรงนั้นอยู่ในระดับที่คุณสามารถใช้ (ab) ได้อย่างเต็มที่

หากคุณมี MCU คุณกำลังพูดถึงหน่วยความจำแฟลชน้อยกว่า 100kB คุณต้องการที่จะเขียนโปรแกรมในภาษาที่มีนามธรรมของหน่วยความจำ: เมื่อฉันประกาศตัวแปรหรืออาร์เรย์มันได้รับหน่วยความจำระยะเวลา; คำหลัก malloc (หรือที่รู้จักว่า "ใหม่" ใน C ++) ควรถูกห้ามไม่ให้ใช้งานในซอฟต์แวร์แบบฝังมากขึ้นหรือน้อยลงยกเว้นในบางครั้งที่มีการโทรครั้งเดียวระหว่างการเริ่มต้นโปรแกรม

นรกมี (บ่อยครั้ง) ในการเขียนโปรแกรมแบบฝังตัวที่ C ไม่ค่อนข้างต่ำพอและคุณต้องทำสิ่งต่าง ๆ เช่นจัดสรรตัวแปรให้กับการลงทะเบียนและเขียนชุดประกอบแบบอินไลน์เพื่อกระชับรูทีนบริการขัดจังหวะ (ISRs) ของคุณ คำหลักเช่น "ระเหย" กลายเป็นสิ่งสำคัญที่จะต้องเข้าใจ คุณใช้เวลามากกับการจัดการหน่วยความจำในระดับบิตไม่ใช่ระดับวัตถุ

ทำไมคุณต้องการหลอกตัวเองให้คิดว่าสิ่งต่าง ๆ ง่ายกว่าที่เป็นจริง

</ พูดจาโผงผาง>