ข้อ จำกัด C ++ เป็นอย่างไรเมื่อเทียบกับภาษา C? [ปิด]

ต่อไปนี้เป็นประโยชน์ของ C ++

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

มีเหตุผลที่เป็นรูปธรรมและสถานการณ์เฉพาะที่ต้องใช้ C มากกว่า C ++ หรือไม่?

อ้างอิงถึงคำถามนี้: Library for generics in C

ไม่ซ้ำกันเนื่องจากคำถามนี้ถามเกี่ยวกับข้อ จำกัด ด้านภาษาและไม่เกี่ยวกับควร / ไม่ควรเรียนรู้ภาษาหนึ่งกับอีกภาษาหนึ่ง

โพสต์ของ Peter Kirkham ให้ข้อมูลมากที่สุดสำหรับฉันโดยเฉพาะอย่างยิ่งเกี่ยวกับปัญหา C99 ที่ฉันไม่ได้พิจารณาดังนั้นฉันจึงยอมรับมัน ขอบคุณคนอื่น ๆ ที่เข้ามามีส่วนร่วม

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

C เป็นภาษาโปรแกรมที่สมบูรณ์ C ไม่ใช่ส่วนย่อยของ C ++ โดยพลการ C ไม่ใช่ส่วนย่อยของ C ++ เลย

นี่คือ C ที่ถูกต้อง:

foo_t* foo = malloc ( sizeof(foo_t) );

เพื่อให้คอมไพล์เป็น C ++ คุณต้องเขียน:

foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );

ซึ่งไม่ถูกต้อง C อีกต่อไป (คุณสามารถใช้แคสต์สไตล์ C ซึ่งในกรณีนี้มันจะคอมไพล์เป็น C แต่ถูกหลีกเลี่ยงโดยมาตรฐานการเข้ารหัส C ++ ส่วนใหญ่และโปรแกรมเมอร์ C หลายคนร่วมเป็นสักขีพยานในความคิดเห็น "don't cast malloc" ใน Stack Overflow) .

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

การใช้ไฟล์ C ตัวแรกในโปรเจ็กต์ที่ฉันกำลังทำนี่คือสิ่งที่จะเกิดขึ้นหากคุณเพียงแค่สลับgcc std=c99สำหรับg++:

sandiego:$ g++ -g  -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3  -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc  src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier

ข้อผิดพลาดทั้งหมด 69 บรรทัดซึ่งสี่รายการเป็น Conversion ที่ไม่ถูกต้อง แต่ส่วนใหญ่เป็นคุณลักษณะที่มีอยู่ใน C99 แต่ไม่มีใน C ++

ไม่ใช่ว่าฉันใช้คุณสมบัติเหล่านั้นเพื่อความสนุก การโอนไปยังภาษาอื่นจะต้องใช้เวลามาก

ดังนั้นจึงเป็นเรื่องผิดที่จะแนะนำอย่างนั้น

[a] C คอมไพเลอร์เกือบจะเป็นคอมไพเลอร์ C ++ จริงๆดังนั้นจึงไม่มีผลกระทบด้านต้นทุนซอฟต์แวร์

มักจะมีผลกระทบด้านต้นทุนที่สำคัญในการย้ายรหัส C ที่มีอยู่ไปยังชุดย่อยขั้นตอนของ C ++

ดังนั้นการแนะนำให้'ใช้คลาส C ++ std :: que เป็นคำตอบสำหรับคำถามที่กำลังมองหาการใช้งานไลบรารีของคิวใน C นั้นหลังจากแนะนำ' ใช้วัตถุประสงค์ C ' และ' เรียกคลาส Java java.util.Queue โดยใช้ JNI 'หรือ'เรียกไลบรารี CPython' - จริงๆแล้ว Objective C เป็นชุดย่อยที่เหมาะสมของ C (รวมถึง C99) และไลบรารี Java และ CPython ทั้งสองสามารถเรียกใช้ได้โดยตรงจาก C โดยไม่ต้องพอร์ตรหัสที่ไม่เกี่ยวข้องกับภาษา C ++

แน่นอนคุณสามารถจัดหา C façadeให้กับไลบรารี C ++ ได้ แต่เมื่อคุณทำ C ++ แล้วก็ไม่ต่างจาก Java หรือ Python

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

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

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

C ++ ไม่ได้รับการสนับสนุนในสภาพแวดล้อมจริงบางอย่างเช่นระบบฝังตัวระดับต่ำ และมีเหตุผลที่ดีสำหรับสิ่งนั้น: C ดีพอสำหรับสิ่งนั้นได้อย่างง่ายดายดังนั้นทำไมต้องใช้สิ่งที่ใหญ่กว่า

ฉันเกลียดการเขียนโปรแกรมใน C ++

อาจมีสาเหตุสองประการดังนี้

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

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

มีข้อโต้แย้งมากมายเกี่ยวกับโปรแกรมฝังตัวประสิทธิภาพและสิ่งต่าง ๆ ฉันไม่ซื้อพวกเขา C ++ เปรียบเทียบกับ C ในพื้นที่เหล่านั้นได้อย่างง่ายดาย อย่างไรก็ตาม:

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

C ++ ช่วยให้คุณยิงปืนได้ไม่สิ้นสุด ซึ่งอาจเป็นเนื้อหาที่ดี แต่อย่างใดคุณมักจะใช้มันมากเกินไป ซึ่งหมายความว่าคุณกำลังปลอมแปลงโซลูชันของคุณด้วยเลเยอร์นามธรรม "ดี" และ "สวย" ทั่วไป ฯลฯ

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

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

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

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

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

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

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

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

ชีวิตนั้นสั้น...

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

พูดจากประสบการณ์ในการสืบทอดและดูแลทั้งสองอย่าง: การออกแบบที่น่ากลัวในภาษา C นั้นยากที่จะเข้าใจคลี่คลายและปรับเปลี่ยนเป็นสิ่งที่ใช้งานได้

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

ถ้าฉันต้องทำงานร่วมกับวิศวกรที่ฉันรู้ว่าจะไม่สามารถสร้างงานออกแบบที่ยอดเยี่ยมได้ฉันควรจะมีอดีตมากกว่าอย่างหลัง

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

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

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

ทำไมต้อง จำกัด การพูดเป็นภาษาอังกฤษ? บางทีคุณอาจเป็นนักเขียนที่สร้างสรรค์กว่าในเซอร์เบีย

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

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

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

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

1. มาตรฐานการเข้ารหัสอาจเป็นเรื่องยากที่จะบังคับใช้อย่างเคร่งครัด
2. อาจเป็นเรื่องยากมากที่จะได้สิ่งที่ดี

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

1. คุณได้รับอนุญาตให้ใช้คอนเทนเนอร์ stl แต่ห้ามใช้เทมเพลตในโค้ดของคุณเอง
2. ผู้คนเริ่มบ่นว่าพวกเขาจะมีประสิทธิผลมากขึ้นหากพวกเขาได้รับอนุญาตให้เขียนโค้ดคลาสนี้หรือคลาสเทมเพลตนั้น
3. มาตรฐานการเข้ารหัสได้รับการแก้ไขเพื่อให้สามารถทำได้
4. เลื่อนความลาดชันไปยังมาตรฐานการเข้ารหัสที่ซับซ้อนเกินไปซึ่งไม่มีใครปฏิบัติตามและใช้รหัสอันตรายที่มาตรฐานควรป้องกันรวมกับระบบราชการส่วนเกินที่อยู่รอบ ๆ มาตรฐาน

(ทางเลือกที่มาตรฐานไม่ได้รับการแก้ไขในขั้นตอนที่ 3 นั้นไม่น่าจะเป็นไปได้ในเชิงประจักษ์เกินกว่าที่จะพิจารณาและจะไม่ดีไปกว่านี้อีกแล้ว)

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

ฉันใช้ C หรืออย่างน้อยก็ส่งออกอินเตอร์เฟส C เมื่อฉันเขียนโค้ดไลบรารี

ฉันไม่ต้องการให้ ABI ยุ่งยาก

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

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

จุดหนึ่งที่ฉันยังไม่เคยเห็นมาก่อนซึ่งฉันคิดว่าสำคัญที่สุด:

ไลบรารีส่วนใหญ่ที่ฉันใช้เป็นประจำทุกวันคือไลบรารี C ที่มีการผูกสำหรับ Python, Ruby, Perl, Java และอื่น ๆ จากสิ่งที่ฉันได้เห็นการรวมไลบรารี C ด้วยการผูกภาษา 19 แบบนั้นง่ายกว่ามาก ห่อไลบรารี C ++

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

ฉันรู้ว่าเป็นไปได้ที่จะผูกไลบรารี C ++ แต่ AFAICT มันไม่เหมือนกัน ฉันเคยใช้ Qt (v3 และ v4) ในภาษาอื่นและมันก็ไม่ได้อยู่ใกล้ที่ดีเท่าที่จะใช้: พวกเขารู้สึกเหมือนเขียน C ++ ในภาษาอื่นไม่ใช่เหมือนไลบรารีดั้งเดิม (คุณต้องส่งซิกเมธอด C ++ เป็นสตริง!)

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

การพัฒนาเคอร์เนลของ Windows ไม่รองรับ c ++ (น่าเศร้า)

คุณสามารถอ่านคำพูดที่สนุกสนานเกี่ยวกับสาเหตุที่ Linus Torvalds ชื่นชอบ C ได้ที่นี่

โค้ดเนทีฟบน mac คือวัตถุประสงค์ -c รหัสดั้งเดิมบนพีซีคือ c (window.h) หรือ c ++ (mfc) สภาพแวดล้อมทั้งสองนี้จะช่วยให้คุณใช้ c โดยมีการเปลี่ยนแปลงเพียงเล็กน้อยหรือไม่มีเลย เมื่อฉันต้องการให้ไลบรารีรหัสเป็นแบบข้ามแพลตฟอร์ม ansi c ดูเหมือนจะเป็นทางเลือกที่ดี

ฉันคิดได้หลายสาเหตุ

อาจไม่มีคอมไพเลอร์ C ++ ที่น่าพอใจ C ++ เป็นภาษาที่ใหญ่กว่ามากและฉันใช้งานคอมไพเลอร์ C บนระบบที่ไม่สามารถจัดการกับ C ++ สมัยใหม่ได้

ผู้ถามหรือคนที่ทำงานด้วยอาจคุ้นเคยกับ C แต่ไม่ใช่ C ++

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

ผู้ถามอาจมีมุมมองที่ล้าสมัยของเส้นโค้งการเรียนรู้ของ C ++ (เมื่อเข้าหาถูกจะง่ายกว่า C หนังสือแนะนำตัวส่วนใหญ่ที่ฉันเคยเห็นไม่ได้เข้าใกล้อย่างถูกต้อง)

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

หากคุณทำงานในสภาพแวดล้อมที่มีสองภาษาคุณอาจใช้ C สำหรับฟังก์ชันระดับต่ำที่สำคัญด้านประสิทธิภาพและภาษาระดับสูงที่ใช้งานได้ดีกว่าเช่น C # / Java สำหรับตรรกะทางธุรกิจ หากใช้รหัส C ++ สำหรับฟังก์ชันเหล่านี้ C-Wrappers จำเป็นสำหรับ JNI / โค้ดที่ไม่มีการจัดการรอบ ๆ และทำให้สิ่งต่างๆซับซ้อนกว่าการใช้ C เพียงอย่างเดียว

ฉันใช้ C ++ กับการเขียนโปรแกรม C ด้วยเหตุผลสองประการ:

• vectorและstringเพื่อให้การจัดการหน่วยความจำอาร์เรย์ออกไปจากฉัน
• การตรวจสอบประเภทที่เข้มงวดและโยนเพื่อเตือนและ / หรือจับความรำคาญทั้งหมดที่ฉันจะพลาดเป็นอย่างอื่น

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

ผมว่า C พกพาสะดวกกว่า ฉันทำงานบางอย่างเมื่อ 5 ปีที่แล้วในการพอร์ตโค้ดไปยังยูนิกซ์หลายรสชาติ (AIX, Irix, HPUX, Linux) รหัส C นั้นง่ายต่อการพอร์ต แต่เรามีปัญหาหลายอย่างในการพอร์ตโค้ด C ++ บางส่วน บางทีมันอาจจะเป็นแค่สภาพแวดล้อมการพัฒนาที่ยังไม่บรรลุนิติภาวะ แต่ฉันค่อนข้างจะใช้ C มากกว่า C ++ ด้วยเหตุนี้ ...

1. C เป็นภาษาง่ายๆ C ++ ไม่ใช่ สำหรับหลาย ๆ คน, C ++ เป็นเพียงซับซ้อนเกินไปที่จะต้นแบบอย่างเต็มที่ดูhttp://en.wikipedia.org/wiki/C%2B%2B#Criticism

2. เนื่องจากความซับซ้อนโปรแกรมเมอร์ที่แตกต่างกันมักจะเชี่ยวชาญเฉพาะส่วนย่อยของภาษาที่แตกต่างกัน มันทำให้การอ่านโค้ดของคนอื่นเจ็บปวด

3. ความซับซ้อนข้อผิดพลาดของภาษาทำให้เกิดความว้าวุ่นใจมากเกินไปและบางครั้งก็ทำร้ายผลผลิต แทนที่จะมุ่งความสนใจไปที่งานตัวเองฉันมักจะพบว่าตัวเองต้องต่อสู้กับภาษา Java / python เป็นทางเลือกที่มีประสิทธิผลมากกว่า

4. การดีบักโค้ด C ที่ใช้งานไม่ได้มักจะง่ายกว่าการดีบักโค้ด C ++ ที่เสีย

5. ซึ่งแตกต่างจาก Java / C # ไลบรารีมาตรฐาน C ++ สามารถทำได้เกินขอบเขตของไลบรารีมาตรฐาน C เพียงเล็กน้อย

6. โปรแกรมเมอร์ชื่อดังบางคนเช่น Linus Torvalds (Linux) และ Richard Stallman (Emacs) ไม่ชอบ C ++

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

มีสามเหตุผลที่ฉันคิดได้ หนึ่งคือ C เหมาะสำหรับระบบฝังตัวมากกว่าเนื่องจากไบนารีมีขนาดเล็กและมีคอมไพเลอร์ C ที่กว้างกว่าในระบบใด ๆ ประการที่สองคือความสามารถในการพกพา: C เป็นภาษาที่เล็กกว่าและโค้ด ANSI C จะรวบรวมได้ทุกที่ ง่ายกว่าที่จะทำลายการพกพาใน C ++ สุดท้ายคือภาษานั่นเอง C ++ นั้นยากกว่าและแน่นอนว่าเป็นภาษาที่ออกแบบมาไม่ดี Torvalds gripes มีรายงานด้านบน คุณอาจต้องการดูคำตอบที่ถูกถามบ่อยของ C ++ ( http://yosefk.com/c++fqa/ )

การพกพาอาจเป็นปัญหา แตกต่างจากคำตอบของ Gordon Carpenter-Thomp ฉันขอแนะนำว่าเป็นการสนับสนุนรันไทม์ของ libstdc ++ เวอร์ชันต่างๆใน linux / unix เวอร์ชันต่างๆ ดูลิงค์นี้สำหรับการสนทนาที่ดีเกี่ยวกับเรื่องนี้ ข้อความที่ตัดตอนมาเล็กน้อย:

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

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

ฉันสามารถทำตามคำแนะนำมากมายได้ที่นี่ทั้งสองทิศทาง แต่ในที่สุดมันก็ลงมาเป็น a) เทียบเคียงง่าย b) ซับซ้อนที่เทียบเคียงได้

ฉันไม่รู้ว่ามีใคร "คิดค้น" แบบวัดความซับซ้อนทางภาษาขึ้นมา

ในระดับ 0-10 ฉันอาจให้คะแนน C ที่ 2 หรือ 3 ในขณะที่ C ++ จะอยู่ระหว่าง 8-10 ฉันขอยืนยันว่า C ++ เป็นหนึ่งในภาษาที่ซับซ้อนที่สุด แต่ฉันไม่รู้เช่น Ada, PL1 หรืออื่น ๆ ดังนั้นอาจจะไม่ซับซ้อนเมื่อเทียบกับภาษาอื่น

C ++ สืบทอดความซับซ้อนทั้งหมดของ C ดังนั้นจึงต้องไม่ต่ำกว่าระดับความซับซ้อนของ C

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

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

สิ่งสำคัญคือเมื่อต้องเดินสายในคุณลักษณะหรือส่วนประกอบใหม่ไปยังระบบเก่าและพันกัน

คุณไม่สามารถทำได้อย่างง่ายดายใน C ++ หากไม่มีเครื่องมือสร้างกราฟการโทรที่ซับซ้อน

คนส่วนใหญ่ดูเหมือนจะคิดว่า C และ C ++ เกี่ยวข้องกัน แต่พวกเขาเข้าใจผิดอย่างน่าเศร้า C ++ เป็นภาษาที่แตกต่างจากภาษาซีอย่างสิ้นเชิง

ในภาษา C ++ คุณคิดในแง่ของวัตถุและความสัมพันธ์ระหว่างกันอย่างไร ในภาษา C คุณคิดในแง่ของ API มันเหมือนกับความแตกต่างระหว่างวันกับ 17

การเปรียบเทียบที่ไม่ดี: หากมีคนเพิ่มภาษาจีนเป็นภาษาอังกฤษและเรียกมันว่าภาษาอังกฤษ ++ คุณอาจไม่สบายใจที่จะเพิ่มบรรทัดภาษาจีนลงในจดหมายรักฉบับล่าสุดของคุณเพราะการแสดงความรักในส่วนนี้ของภาษาอังกฤษ ++ นั้นง่ายกว่ามาก

ต่อไปนี้เป็นสาเหตุทั้งหมดที่อาจเป็นประโยชน์ในการ จำกัด โครงการไว้ที่ C:

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