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


167

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

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

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

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

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

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


5
คำถามด่วน: เมื่อคุณพูดว่าฝังตัวคุณหมายถึงไมโครคอนโทรลเลอร์หรือไม่ ไมโครโปรเซสเซอร์? ฝังตัว x86 / ฝังตัว PC?
J. Polfer

1
ฉันไม่ได้ตั้งใจทำสงครามศักดิ์สิทธิ์ ความตั้งใจที่จะเรียนรู้ว่าข้อโต้แย้งของคุณขัดแย้งกับมันอย่างไร
J. Polfer

2
ก่อนหน้านี้มีคำถามหลายข้อดังนั้นฉันคิดว่าสถานที่ส่วนกลางจะดี
Toby Jaffey

4
C ++ vs embedded เป็นหัวข้อที่ถกเถียงกัน ฉันมีความเห็นที่ดี แต่ฉันไม่คิดว่ามันยุติธรรมที่จะถามคำถามและเล่นที่คะแนนคะแนน ฉันหวังว่าวิกิชุมชนจะทำให้การสนทนามีความสมดุลมากขึ้น
Toby Jaffey

13
นี่เป็นคำถามที่ไม่ดีเนื่องจาก "ฝังตัว" เป็นคุณลักษณะที่ไม่มีความหมายในการตัดสินใจว่าควรใช้ภาษาใดและสัมภาระที่เกี่ยวข้องหรือไม่ ประเด็นคือมีขนาดเล็กเมื่อเทียบกับระบบขนาดใหญ่ที่ระบบขนาดเล็กไม่ได้ใช้งานระบบปฏิบัติการมีหน่วยความจำ จำกัด อาจไม่ใช่ von-Neuman อาจมีข้อ จำกัด ด้านฮาร์ดแวร์ต่าง ๆ เกี่ยวกับสแต็คการโทรสแต็คข้อมูลคุณไม่สามารถจัดสรร Mb แบบไดนามิกได้ หรือแม้แต่ kb เป็นต้นไมโครคอนโทรลเลอร์ส่วนใหญ่เป็นระบบ "เล็ก" โดยทั่วไปแล้วคอมพิวเตอร์แบบบอร์ดเดียวจะฝังตัว แต่โดยทั่วไปแล้วจะเป็นระบบ "ใหญ่"
Olin Lathrop

คำตอบ:


135

ใช่ 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 ในการแก้ปัญหาและบางครั้งก็แสดงอินเทอร์เฟซที่ดีกว่า ให้การศึกษาด้วยตนเองและไม่กลัวที่จะเรียนรู้วิธีการ


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

3
ในบันทึกวิชาเอกวิทยาศาสตร์คอมพิวเตอร์กำลังคลั่งไคล้ในดินแดน EE ที่งานของฉันรหัสที่แย่ที่สุดที่เราเขียนโดย CS สำคัญ เราใช้เวลาตลอดไปพยายามสอนเขาว่าฮาร์ดแวร์คืออะไร เขาสร้างระบบที่มีโครงสร้างโดยใช้ UML และสร้างระบบทั้งหมดขึ้นอยู่กับมันใน java โดยใช้การสืบทอดที่เหมาะสมและอื่น ๆ มันทำงานได้จนกว่าจะมีอะไรเปลี่ยนแปลงและจากนั้นมันก็เป็นงานแก้ไขที่ไม่ดีเพื่อเพิ่มคุณสมบัติหรือการออกแบบใหม่ทั้งหมด รหัสนี้แทบจะไม่สามารถใช้งานได้เพราะเขาสับสนอย่างมากกับการสืบทอด
Kortuk

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

2
UML และ statemachines จริงๆคุณต้องดูเป็นสิ่งที่ Miro Samek ที่state-machine.com เขาสร้างระบบที่มีประสิทธิภาพซึ่งง่ายต่อการปรับโครงสร้างและเปลี่ยนแปลง แต่ต้องใช้เวลาพอสมควร
Jay Atkinson

2
มันขึ้นอยู่กับระบบของคุณและจำนวนหน่วยความจำที่คุณมีอยู่ คุณกำลังเขียนโค้ดบนไมโคร 8-bit พร้อม RAM น้อยมากหรือไม่? ถ้าอย่างนั้นคุณควรหลีกเลี่ยงการใช้อินเทอร์เฟซแบบนามธรรม หากคุณกำลังเขียนอะไรบางอย่างเช่นระบบฝังตัว 32 บิตพร้อมแผ่นหน่วยความจำลองทำดู คุณต้องชั่งน้ำหนักมันจริงๆ ตัวอย่างเช่นทุกครั้งที่คุณติดโลก "เสมือน" ในคลาสนั้นคุณจะได้รับตัวชี้พิเศษซึ่งอาจเป็น 8 บิต, 16 บิตหรือ 32 บิตขึ้นอยู่กับระบบสำหรับทุกอินสแตนซ์เดียวที่คุณประกาศวัตถุนั้น คุณจะไม่รู้ตัวเลยแม้แต่คน
Jay Atkinson

56

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

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

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

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

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

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

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

ขอบคุณสำหรับการป้อนข้อมูล น่าสนใจและคล้ายกันมากกับสิ่งที่ฉันอ่าน
Kortuk

1
การจัดสรรหน่วยความจำแบบไดนามิกจริงแล้วใช้ได้และบางครั้งก็หลีกเลี่ยงไม่ได้ เป็นหน่วยความจำไดนามิกการจัดสรรคืน (และการใช้ซ้ำในภายหลัง) ซึ่งเป็นปัญหา RTTI เป็นหมูหน่วยความจำฉันเห็นด้วยกับมัน แต่ปัญหากับข้อยกเว้นคืออะไร
Wouter van Ooijen

1
@WoutervanOoijen: ปัญหามีข้อยกเว้นคือว่าถ้าfooโทรbarภายในtry/ catchบล็อกและbarสร้างวัตถุบางอย่างและบริการโทรbozซึ่งพ่นยกเว้นระบบมีอย่างใดโทร destructors สำหรับวัตถุที่สร้างขึ้นก่อนที่จะกลับไปควบคุมbar fooหากไม่มีข้อยกเว้นถูกปิดการใช้งานโดยสมบูรณ์barจะไม่มีทางรู้ว่าbozอาจจะมีการโยนหรือไม่และจะต้องมีรหัสพิเศษเพื่อให้เป็นไปได้ ฉันต้องการดูรูปแบบของ C ++ พร้อมกับ "ข้อยกเว้นที่ตรวจสอบแล้ว" เพื่อจัดการกับสิ่งนั้น ถ้ากิจวัตรซึ่งอาจทำให้เกิดข้อยกเว้นยกเว้น ...
supercat

1
... จะต้องมีการประกาศเป็นเช่นนี้จากนั้นก็จะจำเป็นสำหรับการรวบรวมเพื่อรวมรหัสการจัดการข้อยกเว้นในการโทรของกิจวัตรดังกล่าว เพื่อให้แน่ใจว่าการเพิ่มการประกาศที่จำเป็นทั้งหมดในขณะที่หวังว่าการหลีกเลี่ยงสิ่งที่ไม่จำเป็นนั้นจะค่อนข้างเป็นภาระ แต่มันจะอนุญาตให้มีการยกเว้นในสถานที่ที่มีประโยชน์โดยไม่ต้องเพิ่มค่าใช้จ่าย
supercat

3
@WoutervanOoijen: โดยบังเอิญถ้าฉันออกแบบ ABI สำหรับการจัดการข้อยกเว้นบน ARM ฉันจะระบุรหัสที่เรียกรูทีนที่อาจออกจากข้อยกเว้นควรมี R14 ชี้ไปที่ที่อยู่สองไบต์ก่อนที่จะกลับที่อยู่ที่ต้องการ (นี้จะ เกิดขึ้นตามธรรมชาติหากผู้โทรปฏิบัติตามคำสั่ง CALL ด้วยคำ 16 บิต) ที่เรียกว่ากิจวัตรประจำวันก็จะออกจากปกติผ่านทางadd r15,r14,#2แทนmov r15,r14; เพื่อออกจากข้อยกเว้น, ldrhs r0,[r14] / add r15,r14,r0. ไม่มีค่าใช้จ่ายวงจรรอบสำหรับการออกปกติและไม่มีข้อ จำกัด สแต็กเฟรม
supercat

36

ใช่ 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 ของคุณอย่างถูกต้องคุณจะรู้วิธีการใช้ทั้งสองอย่างร่วมกันอย่างมีประสิทธิภาพ


3
นี่เป็นคำตอบที่ดีและสมเหตุสมผลสำหรับคำถาม +1 ไชโย!
vicatcu

1
" a[i] = b[j] * c[k];สามารถสร้างคำสั่งประมาณ 4 หน้าขึ้นอยู่กับลักษณะของตัวแปรเหล่านั้น" หาก MCU / คอมไพเลอร์ของคุณทำสิ่งนี้อาจเป็นเพราะคุณกำลังใช้ซีพียูมือสมัครเล่นในโรงรถจากยุค 80
Lundin

@Lundin - ถอนหายใจ ไม่หมายความว่าคุณกำลังใช้ MCU ขนาดเล็กราคาถูกซึ่งออกแบบมาให้มีขนาดเล็กและราคาถูกที่สุดเท่าที่จะทำได้เพื่อไม่ให้มีสิ่งซับซ้อนเช่นการทำดัชนีสแต็ก
Rocketmagnet

2
@Rocketmagnet ตกลงบางทีในปี 1990? ทุกวันนี้เส็งเคร็ง 8 bitters มาในราคาเดียวกันกับ 32 bitters เหตุผลเดียวที่เหลือสำหรับการเลือกอดีตคือปริมาณการใช้ปัจจุบัน และเกี่ยวกับ 8-bitters เส็งเคร็งเหล่านั้นโดยไม่มีสแต็ค: ถ้าคุณเขียน C แทนแอสเซมเบลอร์สำหรับ MCU ที่มีข้อ จำกัด คุณน่าจะทำผิด 4 หน้าที่สร้างขึ้นนั้นเป็นความผิดของคุณเองสำหรับการเขียนโปรแกรมที่ซับซ้อนเกินไปสำหรับ CPU และ C เป็นเครื่องมือที่ไม่ถูกต้องสำหรับงาน (ฉันเคยทำสิ่งนี้มาแล้วใน Freescale RS08 มันเป็นความคิดที่โง่มาก)
Lundin

@Lundin โปรเซสเซอร์ 32 บิตไม่จำเป็นต้องเร็วกว่า 16 บิต นี่เป็นวิธีที่ชัดเจนในวันที่การเปลี่ยนแปลงโปรแกรม 16-32 บิตเกิดขึ้นในโลกพีซี
Barleyman

24

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

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

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

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

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

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

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

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

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

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

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


2
ตอนนี้ฉันไม่ได้ทดสอบหน่วยในระดับแอปพลิเคชัน (เหนือไดรเวอร์) ในระบบฝังตัวบางระบบ มีค่าบางอย่างของความคิดเห็นทันทีของการทดสอบหน่วยและการกำจัดข้อบกพร่องในช่วงต้นของการพัฒนา แต่กระบวนทัศน์ TDD ทั้งหมดที่จะให้กำเนิดการออกแบบดูเหมือนว่าฉันจะได้รับความคิดเล็กน้อย ฉันชอบที่จะใช้เวลาสักครู่เพื่อ "คิด" เกี่ยวกับปัญหาและวาดแผนภาพออกมาในหัวของฉันบนกระดาษหรือบนกระดานไวท์บอร์ดก่อนเริ่มเขียนโค้ด ฉันยังคิดว่า TDD สนับสนุนให้ตลาดไม่ทำการวิจัยล่วงหน้าเกี่ยวกับข้อกำหนดเพราะมันควรจะช่วยเปลี่ยนแปลงความต้องการอย่างต่อเนื่อง
Jay Atkinson

2
และเพื่อให้ทราบขั้นสุดท้ายเกี่ยวกับความคิดเห็นที่ยาวมากของฉัน .. เราไม่ต้องการผู้เชี่ยวชาญด้านภาษาในการออกแบบ เราต้องการนักออกแบบผู้เชี่ยวชาญที่สามารถใช้ภาษาได้
Jay Atkinson

1
PRD = เอกสารข้อกำหนดผลิตภัณฑ์ MRD = เอกสารข้อกำหนดด้านการตลาด TRD = เอกสารข้อกำหนดทางเทคนิค TDD = การทดสอบการพัฒนาแบบขับเคลื่อน
Jay Atkinson

1
@ Mark - ฉันเห็นด้วยกับความรู้สึกในการออกแบบของคุณ แต่เฉพาะจุด ผมคิดว่าหนักออกแบบขึ้นด้านหน้าทำงานจ่ายออกหากมี) ความต้องการที่คุณกำลังมีความเสถียรธรรม / รู้จักกันและ b) นักพัฒนาทำออกแบบที่มีประสบการณ์ ในครั้งก่อน งานฉันถูกมอบหมายให้ทำการออกแบบและมันถูกกำหนดเวลาอย่างมากโดยหัวหน้าทีมของฉันและฉันคิดว่า "ช่างเป็นเรื่องที่น่าทำ! ออกแบบหน้าขึ้นช่วยประหยัดเงิน (เทียบกับรหัสหนังสือที่สมบูรณ์)?" แต่ในการเขียนโปรแกรมฉันค้นพบสิ่งต่าง ๆ มากมายที่ฉันไม่รู้ว่าจะมองหา ถ้าฉันออกแบบและลดจำนวนเวลาในการเขียนลงไปมันคงจะเป็นการเสียเปล่า JME
J. Polfer

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

17

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

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

สำหรับระบบเรียลไทม์ 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 ++ ในระบบขนาดเล็ก (= ไมโครคอนโทรลเลอร์)


15

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

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

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

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

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


ฉันเห็นด้วยกับการอ้างอิงถึงระบบขนาดเล็ก แต่ฉันคิดว่าเรามีคำจำกัดความที่แตกต่างของระบบขนาดเล็ก เมื่อคุณมี ROM ขนาด 1kB และรหัส C ที่เขียนได้ดีจะใช้เวลาทั้งหมด 1 ไบต์ของ ROM นั่นคือระบบขนาดเล็ก
Kortuk

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

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

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

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

11

ฉันหวังว่าจะเพิ่มแสงสว่างมากกว่าความร้อนในการสนทนานี้เกี่ยวกับ 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 ++


นอกจากคำตอบของฉันแล้ว :) คนรัก C ++ คนนี้จะเป็นใคร? โปรไฟล์ของเขาระบุว่า "เห็นได้ชัดว่าผู้ใช้รายนี้ชอบที่จะแสดงความลึกลับเกี่ยวกับพวกเขา" (ภาษาอังกฤษไม่ดี BTW) แต่ AHA ที่ตั้งคือ "Bochum, Germany" ..... พบกันที่การประชุม!
Wouter van Ooijen

Ah yeah อัปเดตโปรไฟล์ของฉัน;) ดีใจที่ได้ทราบว่าการมาที่ emBO ++ ของคุณจะเป็นเรื่องที่ดีมาก
odinthenerd

10

พื้นหลังของฉัน: เพิ่งออกจากการฝึกอบรมโรงเรียนภายใต้โปรแกรมเมอร์ 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 ในโครงการที่กำลังจะมาถึง - หวังว่าฉันจะสามารถทดสอบการอ้างสิทธิ์ของฉันได้ที่นั่น

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

ในจุดที่สองของคุณเช่นกัน: การใช้วิธีการออกแบบ OOP เพียงอย่างเดียวไม่ได้ทำให้เกิดการแบ่งรหัสมากขึ้น การมีการออกแบบฐานที่ดีนั้นมีวิธีการแสดงออกถึงการออกแบบที่เหลืออยู่สำหรับนักพัฒนา OOP ไม่ได้กำหนดว่าคุณแยกรหัสของคุณออกมาอย่างถูกต้องมีตัวเลือกอื่นและมากกว่านั้นลักษณะที่คุณทำเช่นนั้น แต่แน่นอนว่ามันไม่บังคับใช้การออกแบบที่ดีซึ่งขึ้นอยู่กับนักพัฒนา
Mark

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

@ Mark - ฉันเห็นด้วย มันเป็นกระบวนการเรียนรู้สำหรับฉัน
J. Polfer

7

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

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

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

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

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


1
ฉันเคยยอมรับว่าการปล่อยรหัสเป็นปัญหา แต่เมื่อเร็ว ๆ นี้ดูเหมือนว่าขนาดแฟลชมีอิทธิพลต่อราคาของไมโครคอนโทรลเลอร์น้อยมากน้อยกว่าขนาด RAM หรือจำนวนหมุดของ IO
Wouter van Ooijen

อาร์กิวเมนต์ในหน่วยความจำแบบไดนามิกเป็น IMO สำคัญกว่า ฉันเคยเห็นระบบอุตสาหกรรมที่สามารถทำงานได้หลายสัปดาห์โดยไม่หยุดยั้ง แต่เลเยอร์การวินิจฉัย (เขียนด้วย C ++) จะ จำกัด เวลาในการรีสตาร์ทเป็นเวลา 12 ชั่วโมง
Dmitry Grigoryev

6

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

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

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

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


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

การตกลงทั้งหมดในคลาสแค็ปซูลและคลาส ผู้ประกอบการมากไปและรับมรดกไม่มาก
pingswept

1
ฮ่า ๆ , ใช่, การบรรทุกเกินพิกัดสามารถใช้เพื่อทำให้ฟังก์ชันของโค้ดสับสน หากมีผู้ปฏิบัติงานมากไปก็จำเป็นต้องมีเหตุผลที่ชัดเจนหรือไม่ดำเนินการเลย ควรใช้การสืบทอดในบางกรณีที่คุณกำลังทำอะไรบางอย่างที่เหมือนกับผู้ปกครองที่มีการเพิ่มบางอย่าง ฉันคิดว่าฉันจะไม่ใช้ทุกฟังก์ชั่นใน OOP ฉันใช้ทั้งสองอย่าง แต่ในระบบฝังตัวไม่สามารถนึกถึงกรณีที่ฉันจะทำ อย่างที่ฉันคิดว่าคอมไพเลอร์ที่มีความยาวไม่เกิน 80 ตัวอักษรสำหรับชื่อตัวแปรควรจะถูกตัดทิ้งทันที
Kortuk

2
ฉันเพียงแค่โยนขึ้นในปากของฉันเล็ก ๆ น้อย ๆ ที่คิดว่าการเขียนโปรแกรม MCU ในหลามที่ ...
vicatcu

คุณไม่ได้เป็นคนเดียว แต่ถ้ามันทำงานได้ดีและมีประสิทธิภาพฉันสามารถให้อภัย
Kortuk

6

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

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

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

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

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

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


2
ฉันต้องไม่เห็นด้วยที่นี่ไม่มีจุดทันทีที่ C ++ กลายเป็นที่ยอมรับเนื่องจากทรัพยากรระบบการออกแบบที่ดีสามารถรักษารอยเท้าของ C ++ ที่รอยเท้าของ C คือ ผลลัพธ์นี้ในรหัสด้วยการออกแบบ OOP ที่ใช้พื้นที่เดียวกัน การเขียน C ไม่ดีอาจเป็นสิ่งที่ไม่ดี
Kortuk

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

4

มีคุณสมบัติบางอย่างของ 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 เท่านั้น

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



@Joby Taffey: ฉันเดาว่าฉันแก้ไขโพสต์ของฉันเพื่อละเว้นการพูดถึงว่าผู้สร้าง C ++ ไม่กระตือรือร้นในชุดย่อยที่ฝังตัว ฉันรู้ว่ามีความพยายาม แต่จากความเข้าใจของฉันพวกเขาไม่ได้รับทุกสิ่ง ฉันคิดว่าจะมีการใช้งานที่แน่นอนสำหรับภาษาที่ได้มาตรฐานซึ่งจะรองรับโปรเซสเซอร์ 8 บิตและคุณสมบัติต่าง ๆ เช่นที่ฉันอธิบายไว้ข้างต้นจะดูเหมือนมีประโยชน์บนแพลตฟอร์มใด ๆ คุณเคยได้ยินภาษาที่เสนอสิ่งต่าง ๆ เช่น # 3 ด้านบนหรือไม่ ดูเหมือนว่าจะมีประโยชน์มาก แต่ฉันไม่เคยเห็นภาษาใดเสนอเลย
supercat

"บิดาของ C ++" ไม่มีประสบการณ์ในการเขียนโปรแกรมระบบฝังตัวดังนั้นทำไมทุกคนจะสนใจความเห็นของเขา?
Lundin

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

... แต่นั่นจะต้องให้คอมไพเลอร์เสียความพยายามพอสมควรในการรวบรวมการแทนที่ที่อาจเกิดขึ้นซึ่งท้ายที่สุดจะถูกทิ้ง ความสามารถในการพูดอย่างละเอียดยิ่งขึ้น "ถ้านี่เป็นค่าคงที่ให้ทำสิ่งนี้มิฉะนั้นทำสิ่งนี้" โดยไม่มี "การเริ่มต้นผิด ๆ " จะดูเหมือนเป็นวิธีที่สะอาดกว่า
supercat

3

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 และข้อยกเว้น: อย่าใช้พวกเขาในระบบฝังตัว หลีกเลี่ยงค่าใช้จ่ายทั้งหมด !!


2

พื้นหลังของฉันฝังตัว (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); ทั้งหมดคือความเศร้าโศก


2
มันเป็นเรื่องง่ายไหมที่จะค้นหาไมโครคอนโทรลเลอร์ที่รองรับ Java? ฉันคิดว่านี่จะ จำกัด ตัวเลือกอย่างมาก และประสบการณ์ของคุณเกี่ยวกับการลงโทษการปฏิบัติงาน (เนื่องจากในยูเอสเอสคุณมักจะไม่มี JIT) สิ่งที่เกี่ยวกับผลกระทบของการคาดเดา GC ในระบบเรียลไทม์?
fceconel

2
มี MCUs อะไรบ้างที่สนับสนุน Java แบบฝัง?
J. Polfer

www.ajile.com สำหรับผู้เริ่มต้น
ทิม Williscroft

+1 สำหรับ Ada มันมีหลายอย่างที่ฝังอยู่ในนั้นรวมถึง Arduinos
Brian Drummond

portable java VM สำหรับ micros ที่เขียนใน c เป็นโอเพนซอร์ส dmitry.co/index.php?p=./04.Thoughts/...
Tim Williscroft

-2

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


6
ฉันไม่แน่ใจว่าสิ่งนี้จะเพิ่มการสนทนา
Dave Tweed

-3

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

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

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

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

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

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


ปัญหาของฉันที่นี่เป็นเพียงเพราะเหตุใดฉันต้องการทราบถึงความซับซ้อนของไดรเวอร์ที่เขียนขึ้นเพื่อควบคุม USART1 หากได้รับการพัฒนาเต็มที่เพื่อจัดการกับอินเทอร์เฟซ
Kortuk

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

1
ภาษาทั้งหมดนั้นดีสำหรับบางสิ่ง C ++ เร็วมาก OOP ถ้าทำได้ดีทำให้นักพัฒนาหลายคนทำงานในแบบขนานและรหัสสำหรับสิ่งที่ไม่รู้จักได้ง่ายขึ้น ฉันคิดว่านี่เป็นเหตุผลว่าทำไมมันถึงมีแรงฉุดมากในการพัฒนาเกม
Toby Jaffey

1
ใช่ฉันเห็นด้วย. เหตุผลที่ฉันเห็นมันสำหรับโลกที่ฝังตัวนั้นเป็นเพราะคุณสมบัติและฟังก์ชั่นที่เพิ่มเข้ามามากมายของระบบต่าง ๆ ที่มีอยู่แล้วและระบบใหม่ที่กำลังพัฒนา โครงการใหญ่ขึ้นเรื่อย ๆ ไม่ว่าเราจะใช้เวลาพัฒนาพวกเขานานขึ้นหรือเราเริ่มใช้และบิดเบือนสิ่งที่ CS โลกได้ทำไปแล้วบนพีซี
Kortuk

5
อีกคนที่ไม่เข้าใจภาษา C ++ อย่างถูกต้อง มันทำให้ฉันประหลาดใจเสมอว่ามีกี่คน
Rocketmagnet
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.