คำถามติดแท็ก c++

เหตุใด ISO / ANSI จึงไม่ได้มาตรฐาน C ++ ที่ระดับไบนารี มีปัญหาเรื่องความสะดวกในการพกพากับ C ++ ซึ่งเป็นเพราะขาดมาตรฐานในระดับไบนารีเท่านั้น Don Boxเขียน (อ้างจากหนังสือของเขาEssential COM , ตอนที่COM เป็น C ++ ที่ดีกว่า ) C ++ และการพกพา เมื่อตัดสินใจที่จะทำเพื่อแจกจ่ายคลาส c ++ เป็น DLL ที่หนึ่งจะต้องเผชิญกับหนึ่งในจุดอ่อนพื้นฐานของภาษา C ++ , ที่อยู่, ขาดมาตรฐานในระดับไบนารี แม้ว่ากระดาษทำงานฉบับร่าง ISO / ANSI C ++ พยายามที่จะประมวลผลว่าโปรแกรมใดจะรวบรวมและผลกระทบทางความหมายของการเรียกใช้จะเป็นอย่างไร ครั้งแรกที่ปัญหานี้จะเห็นได้ชัดคือเมื่อไคลเอ็นต์พยายามเชื่อมโยงกับไลบรารีนำเข้าของ FastString DLL จากสภาพแวดล้อมการพัฒนา C ++ …

14 c++  dll  ansi  iso 

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

14 programming-languages  c++  complexity  game-development 

เรามักจะใช้ c ++ structs เพื่อกำหนดโครงสร้างข้อมูลเมื่อเทียบกับคลาสซึ่งสามารถเป็นโมดูลที่สมบูรณ์พร้อมเมธอดสมาชิก ตอนนี้ลึกลงไปเรารู้ว่าพวกเขาทั้งสองเหมือนกัน (พูดอย่างหลวม ๆ ) ความจริงที่ว่าเรามักจะใช้ / รักษา structs เป็นข้อมูลหน่วยงานเท่านั้นสร้างความอยากนี้ที่เราไม่ได้เพิ่มตัวสร้างเริ่มต้นเช่นกัน แต่คอนสตรัคเตอร์นั้นยอดเยี่ยมอยู่เสมอพวกเขาทำให้สิ่งต่าง ๆ ง่ายขึ้นและช่วยกำจัดข้อผิดพลาด มันจะขมวดคิ้วถ้าเพิ่มตัวสร้างเริ่มต้นให้กับโครงสร้างข้อมูลของฉัน? การใช้Constructor ที่เป็นค่าเริ่มต้นยังทำให้โครงสร้าง Non-POD (ชนิดข้อมูลเก่าแบบเดิม) จัดทำตามเกณฑ์อื่น ๆ เพื่อให้สิ่งต่าง ๆ ในมุมมองพิจารณาตัวอย่างง่าย ๆ แต่ในความเป็นจริง struct จะใหญ่กว่ามาก struct method { char name[32]; float temperature; int duration; }; ทุกครั้งที่ฉันสร้างวิธีการฉันต้องกังวลเกี่ยวกับ (พูดน้อยที่สุด) ถ้าฉันลืมตั้งค่าบางอย่าง ลองนึกภาพฉันลืมที่จะตั้งค่าtemperatureและใช้วิธีการกับระบบซึ่งตอนนี้เป็นค่าสูงแบบสุ่มและทำให้เกิดการทำร้ายร่างกาย หรือฉันลืมที่จะตั้งค่าdurationและตอนนี้วิธีการใช้ตัวเองสำหรับช่วงเวลาสูงที่ไม่รู้จัก ทำไมฉันต้องรับผิดชอบในการเริ่มต้นวัตถุทุกครั้งแทนที่จะใช้ตัวสร้างซึ่งรับประกันได้หรือไม่

14 c++  object-oriented  programming-practices 

สำหรับการหลีกเลี่ยงการทำซ้ำที่ไม่เกี่ยวข้องกับ C ++ const มีกรณีที่ const_cast จะทำงานได้ แต่ฟังก์ชั่น const ส่วนตัวที่ส่งกลับไม่ใช่ const จะไม่? ในรายการC ++ ของ Scott Meyers ที่มีประสิทธิผล 3 เขาแนะนำว่า const_cast ที่รวมกับการส่งสัญญาณคงที่นั้นเป็นวิธีที่มีประสิทธิภาพและปลอดภัยในการหลีกเลี่ยงรหัสซ้ำเช่น const void* Bar::bar(int i) const { ... return variableResultingFromNonTrivialDotDotDotCode; } void* Bar::bar(int i) { return const_cast<void*>(static_cast<const Bar*>(this)->bar(i)); } เมเยอร์สอธิบายต่อไปว่าการใช้ฟังก์ชัน const เรียกฟังก์ชันที่ไม่ใช่ const นั้นเป็นอันตราย รหัสด้านล่างคือตัวอย่างที่แสดงให้เห็น: ตรงกันข้ามกับข้อเสนอแนะของเมเยอร์สบางครั้ง const_cast รวมกับตัวบล็อกคงเป็นอันตราย บางครั้งฟังก์ชั่น …

14 c++  dry  const 

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

14 c++ 

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

14 c++  coding-style  const 

สมมติว่าฉันต้องการมีข้อความเอาต์พุตหลายประเภทในรหัสของฉัน หนึ่งในนั้นคือDEBUGซึ่งจะถูกพิมพ์เท่านั้นเมื่อรวบรวมรหัสในโหมด Debug โดยปกติฉันจะต้องเขียนบางอย่างเช่น #ifdef DEBUG std::cout << "Debug message" << std::endl; #endif ซึ่งค่อนข้างยุ่งยากและน่ารำคาญในหลาย ๆ ที่ เป็นวิธีปฏิบัติที่ดีในการกำหนดแมโครสำหรับข้อมูลโค้ดดังนั้นคุณจะใช้วิธีนี้หรือไม่ MSG_DEBUG("Debug message") หรือมีวิธีอื่นที่สวยงามกว่าวิธีจัดการกับมันโดยไม่มีมาโคร ฉันสนใจโซลูชันที่เป็นไปได้ทั้งใน C และ C ++ เนื่องจากฉันใช้ทั้งสองภาษาในโครงการที่แตกต่างกัน

13 c++  c  macros 

ฉันเสร็จหนึ่งในโครงการ C ++ ที่เร็วที่สุดซึ่งก็คือ (ตามกรอบ) ที่ควรจะเป็นข้ามแพลตฟอร์ม ฉันพัฒนาโครงการอย่างสมบูรณ์ใน Windows และ Visual Studio โดยคิดว่าเนื่องจากห้องสมุดเป็นแพลตฟอร์มข้ามแพลตฟอร์มทั้งหมดดังนั้นการทำ OSX build "ในภายหลัง" จึงเป็นเรื่องเล็กน้อย สิ่งนี้กลับกลายเป็นว่าไม่ใช่กรณี แต่ "รหัส Windows" ทำงานไม่ถูกต้องและมีข้อผิดพลาดในการรวบรวมเพื่อแก้ไข เทคนิคใดที่มีอยู่ก่อนเพื่อให้แน่ใจว่ารหัสเข้ากันได้กับทุกแพลตฟอร์ม? การพัฒนาแพลตฟอร์มทั้งหมดพร้อมกันดังนั้นจึงทดสอบโค้ดกับทุกแพลตฟอร์มในเวลาเดียวกันเมื่อมีการเพิ่มฟีเจอร์ใหม่แทนที่จะพัฒนาแพลทฟอร์มรุ่นที่แตกต่างกันหลังจากนั้นหรือไม่ (*) มองหาคำแนะนำเฉพาะที่ไม่ได้ขึ้นอยู่กับเครื่องมือ แต่เป็น "กระบวนการพัฒนา" ที่ช่วยให้สามารถทำงานร่วมกันได้ข้ามแพลตฟอร์มโดยไม่คำนึงถึงเครื่องมือที่ใช้ เช่นเดียวกับ (*) ด้านบน โดยเฉพาะฉันกำลังพัฒนาปลั๊กอิน VST ด้วย WDL-OL ( https://github.com/olilarkin/wdl-ol ) และห้องสมุด DSP ข้ามแพลตฟอร์ม โครงการ WDL-OL มีทั้งโครงการ VS และ Xcode ตั้งค่า แต่ฉันเดาว่าปัญหามาจากไลบรารีและจากนั้นความแตกต่างในคอมไพเลอร์

13 c++  development-process  cross-platform 

เมื่อฉันเรียนรู้ C ++ นานมาแล้วมันเน้นอย่างมากกับฉันว่าส่วนหนึ่งของจุดของ C ++ คือเหมือนลูปมี "loop-invariants" คลาสยังมีค่าคงที่ที่เกี่ยวข้องกับอายุการใช้งานของวัตถุ - สิ่งที่ควรเป็นจริง เพราะตราบเท่าที่วัตถุยังมีชีวิตอยู่ สิ่งที่ควรกำหนดโดยผู้สร้างและเก็บรักษาไว้โดยวิธีการ การห่อหุ้ม / การควบคุมการเข้าถึงมีไว้เพื่อช่วยให้คุณบังคับใช้ค่าคงที่ Raii เป็นสิ่งหนึ่งที่คุณสามารถทำได้กับความคิดนี้ ตั้งแต่ C ++ 11 ตอนนี้เรามีความหมายย้าย สำหรับคลาสที่รองรับการย้ายการย้ายจากวัตถุไม่สิ้นสุดอย่างเป็นทางการตลอดอายุการย้ายควรจะปล่อยให้มันอยู่ในสถานะ "ถูกต้อง" บางอย่าง ในการออกแบบชั้นเรียนเป็นเรื่องที่ไม่ถูกต้องหรือไม่หากคุณออกแบบชั้นเรียนเพื่อให้ค่าคงที่ของชั้นเรียนถูกเก็บรักษาไว้จนถึงจุดที่ถูกย้ายออกไป หรือว่าไม่เป็นไรถ้ามันจะช่วยให้คุณทำให้มันเร็วขึ้น หากต้องการทำให้เป็นรูปธรรมสมมติว่าฉันมีประเภททรัพยากรที่ไม่สามารถคัดลอกได้ แต่เคลื่อนย้ายได้เช่น: class opaque { opaque(const opaque &) = delete; public: opaque(opaque &&); ... void mysterious(); void mysterious(int); void mysterious(std::vector<std::string>); }; และด้วยเหตุผลใดก็ตามฉันจำเป็นต้องทำ …

13 c++  object-oriented-design  c++11  invariants 

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

13 c++  naming-standards 

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

13 java  c++  performance  heap  collections 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา ฉันวางคำถามนี้ให้โปรแกรมเมอร์ C ++ เพราะ: ก) โปรแกรมเมอร์ C ++ เท่านั้นที่สามารถตัดสินข้อดีทางเทคนิคของตัวอย่าง; b) มีเพียงโปรแกรมเมอร์เท่านั้นที่จะรู้สึกถึงอารมณ์ของโปรแกรมเมอร์คนอื่นที่เขียนโค้ดแบบนี้ ฝ่ายทรัพยากรบุคคลและกรรมการตระหนักว่ามีปัญหาเพียงเพราะพวกเขาเห็นหลักฐานในสนาม มันเป็นการโทรของฉันไม่ว่าเราจะให้โปรแกรมเมอร์มีเวลามากกว่านี้หรือไม่ ข้อผิดพลาดหลายอย่างอยู่ในระดับพื้นฐานมาก - คำถามของฉัน (สำหรับโปรแกรมเมอร์) คือว่าคนที่ยอมรับว่าเป็นนักพัฒนา C ++ อาวุโสควรได้รับประโยชน์จากข้อสงสัยจากตัวอย่างของรหัสปัจจุบันหรือไม่ ผู้ที่ไม่ใช่โปรแกรมเมอร์ - แม้แต่คนที่อยู่นอกการเขียนโปรแกรม C ++ - ไม่สามารถตัดสินใจเรื่องนี้ได้ สำหรับพื้นหลังฉันได้รับมอบหมายงานบริหารนักพัฒนาให้กับ บริษัท ที่มีชื่อเสียง พวกเขามีนักพัฒนาเดียวที่มีความเชี่ยวชาญในการเข้ารหัส C ++ ทั้งหมดของพวกเขา (ตั้งแต่ตลอดไป) แต่คุณภาพของงานเป็นสุดซึ้ง การตรวจสอบรหัสและการทดสอบพบว่ามีปัญหามากมายหนึ่งในปัญหาที่แย่ที่สุดคือความจำรั่ว นักพัฒนาซอฟต์แวร์ไม่เคยทดสอบโค้ดของเขาว่ามีรอยรั่วและฉันค้นพบว่าแอปพลิเคชันอาจรั่วไหลไปหลาย …

13 c++  management  training 

ฉันมีคลาสซึ่งล้อมคลาสอื่นที่เป็นประเภทพื้นฐานทั่วไป เนื่องจากอินเตอร์เฟสประเภทฐานมีขนาดค่อนข้างใหญ่จึงเกี่ยวข้องกับการเขียนฟังก์ชั่นการส่งผ่านจำนวนมาก ฉันกำลังมองหาวิธีที่จะหลีกเลี่ยงปัญหานี้ ลองทำตัวอย่าง: Car / \ Volvo VolvoWithTrailer ตอนนี้ฉันต้องติดตั้งฟังก์ชั่นแต่ละอย่างในอินเทอร์เฟซสำหรับรถยนต์ของ VolvoWithTrailer และเรียกใช้ฟังก์ชั่นที่เหมาะสมบนวัตถุที่ห่อหุ้มวอลโว่ยกเว้นอาจ GetMaxSpeed ​​() ซึ่งจะคืนสิ่งที่ต่ำกว่า โดยทั่วไปฉันจะมีฟังก์ชั่นมากมายเช่น int VolvoWithTrailer::GetNumSeats() { return mVolvo.GetNumSeats() } วิธีที่ชัดเจนในการแก้ไขปัญหานี้คือการทำให้ VolvoWithTrailer เป็น subclass ของ Volvo Car | Volvo | VolvoWithTrailer แต่ดูเหมือนว่าจะละเมิดหลักการของการสนับสนุนการแต่งมากกว่ามรดก ฉันจะหลีกเลี่ยงการเขียนโปรแกรมเสริมเหล่านี้ได้อย่างไร (ภาษาคือ C ++) หรือ - ถ้านั่นคือตำแหน่งของคุณ - ทำไมฉันต้องเขียนพวกเขา / แค่ใช้การสืบทอด? มีแม่แบบเวทย์มนตร์ที่สามารถช่วยได้หรือไม่?

13 c++  inheritance  templates  composition 

ใหม่ไปที่ C ++! ดังนั้นฉันจึงอ่านสิ่งนี้: http://www.learncpp.com/cpp-tutorial/110-a-first-look-at-the-preprocessor/ หัวยาม เนื่องจากไฟล์ส่วนหัวสามารถรวมไฟล์ส่วนหัวอื่น ๆ จึงเป็นไปได้ที่จะสิ้นสุดในสถานการณ์ที่ไฟล์ส่วนหัวรวมหลายครั้ง ดังนั้นเราจึงกำหนดให้ตัวประมวลผลล่วงหน้าเพื่อหลีกเลี่ยงปัญหานี้ แต่ฉันไม่แน่ใจ - ทำไมคอมไพเลอร์ไม่สามารถทำได้เพียงแค่ ... ไม่นำเข้าสิ่งเดียวกันสองครั้ง เนื่องจากการ์ดส่วนหัวนั้นเป็นทางเลือก (แต่เห็นได้ชัดว่าเป็นการปฏิบัติที่ดี) มันทำให้ฉันคิดว่ามีสถานการณ์เมื่อคุณต้องการนำเข้าบางสิ่งบางอย่าง แม้ว่าฉันจะไม่สามารถนึกถึงสถานการณ์ดังกล่าวได้เลย ความคิดใด ๆ

13 c++  compiler 

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

13 c#  c++  language-design  multiple-inheritance