Những hạn chế của C ++ so với ngôn ngữ C là gì? [đóng cửa]


116

Sau đây là những lợi ích của C ++

  • C ++ cung cấp các tính năng cụ thể mà họ đang yêu cầu
  • Trình biên dịch C của họ gần như chắc chắn thực sự là trình biên dịch C ++, vì vậy không có tác động về chi phí phần mềm
  • C ++ cũng di động như C
  • Mã C ++ có thể hiệu quả như C (hoặc hơn thế, hoặc ít hơn)

Có bất kỳ lý do cụ thể và tình huống cụ thể nào, nơi người ta phải sử dụng C thay vì C ++ không?

Tham khảo câu hỏi này: Thư viện thuốc generic trong C

Không trùng lặp, vì câu hỏi này hỏi về giới hạn ngôn ngữ chứ không phải về việc nên / không nên học ngôn ngữ này qua ngôn ngữ khác.

Bài đăng của Peter Kirkham đối với tôi là nhiều thông tin nhất, đặc biệt liên quan đến các vấn đề C99 mà tôi chưa xem xét, vì vậy tôi đã chấp nhận nó. Cảm ơn tất cả những người khác đã tham gia.


12
Không quan trọng câu hỏi này có nhằm mục đích tranh luận hay không, nó vẫn là như vậy. Sự lựa chọn ngôn ngữ cho một dự án chính xác là: một sự lựa chọn.
Bombe

7
@bombe chúng ta không nên thảo luận về cách đưa ra những lựa chọn sáng suốt sao?



10
Không phải là mỉa mai khi bạn đưa ra lời khuyên cho các lập trình viên C chuyển sang C ++ rằng họ sẽ tiếp thu ý tưởng của bạn như bạn sẽ thế, nếu một lập trình viên C nói với bạn rằng bạn nên từ bỏ C ++ và chuyển sang C?
Warren P

Câu trả lời:


136

Điều này được thúc đẩy bởi một câu trả lời mà tôi đã đưa ra cho một câu hỏi hiện tại hỏi về thư viện chung cho C - người hỏi đặc biệt nói rằng họ không muốn sử dụng C ++.

C là một ngôn ngữ lập trình hoàn chỉnh. C không phải là một tập con tùy ý của C ++. C hoàn toàn không phải là một tập con của C ++.

Đây là C hợp lệ:

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

Để làm cho nó biên dịch dưới dạng C ++, bạn phải viết:

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

mà không hợp lệ C nữa. (bạn có thể sử dụng kiểu ép kiểu C, nó sẽ biên dịch trong trường hợp nào bằng C, nhưng bị hầu hết các tiêu chuẩn mã hóa C ++ và nhiều lập trình viên C xa lánh; hãy chứng kiến ​​nhận xét "không ép kiểu" trên Stack Overflow) .


Chúng không phải là cùng một ngôn ngữ, và nếu bạn có một dự án hiện có bằng C, bạn không muốn viết lại nó bằng một ngôn ngữ khác chỉ để sử dụng một thư viện. Bạn muốn sử dụng các thư viện mà bạn có thể giao tiếp bằng ngôn ngữ bạn đang làm việc. (Trong một số trường hợp, điều này có thể thực hiện được với một vài extern "C"hàm trình bao bọc, tùy thuộc vào cách thức mẫu / nội tuyến của thư viện C ++.)

Lấy tệp C đầu tiên trong dự án mà tôi đang thực hiện, đây là điều sẽ xảy ra nếu bạn chỉ đổi gcc std=c99lấy 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

Trong tổng số 69 dòng lỗi, bốn trong số đó là các chuyển đổi không hợp lệ, nhưng chủ yếu là đối với các tính năng tồn tại trong C99 nhưng không có trong C ++.

Nó không giống như tôi đang sử dụng những tính năng đó để giải trí. Sẽ mất nhiều công sức để chuyển nó sang một ngôn ngữ khác.

Vì vậy, rõ ràng là sai khi đề xuất rằng

[a] Trình biên dịch C gần như chắc chắn thực sự là trình biên dịch C ++, vì vậy không có tác động về chi phí phần mềm

Thường có những tác động chi phí đáng kể trong việc chuyển mã C hiện có sang tập con thủ tục của C ++.

Vì vậy, đề xuất 'sử dụng C ++ std :: queue class' như một câu trả lời cho câu hỏi tìm kiếm triển khai thư viện của một hàng đợi trong C sẽ nhẹ nhàng hơn so với đề xuất 'sử dụng mục tiêu C''gọi lớp Java java.util.Queue bằng JNI' hoặc 'gọi thư viện CPython' - Mục tiêu C thực sự là một tập hợp chính xác của C (bao gồm C99), và các thư viện Java và CPython đều có thể gọi trực tiếp từ C mà không cần phải chuyển mã không liên quan sang ngôn ngữ C ++.

Tất nhiên bạn có thể cung cấp một mặt tiền C cho thư viện C ++, nhưng một khi bạn đang làm điều đó thì C ++ không khác gì Java hoặc Python.


21
Đúng. Kiểu ép kiểu C khá bình thường khi bạn sử dụng malloc. Khi sử dụng malloc, bạn thực hiện nó ở trong tập con c. Nếu bạn muốn lập trình kiểu C ++, bạn sẽ sử dụng toán tử new, không phải static_cast + malloc.
Suma

33
Nói rằng C không phải là một tập con của C ++ là vô cùng phức tạp. Chắc chắn, bạn có thể nói rằng bất kỳ cấu trúc nào có thành viên gọi là "class" sẽ không biên dịch, nhưng nó thực sự chỉ là những sửa đổi nhỏ được yêu cầu và hầu hết các trình biên dịch đều có các tùy chọn để thêm một vài tính năng chỉ C vào C ++.
Kaz Dragon

27
Theo như ví dụ về malloc của bạn, việc thêm một dàn diễn viên sẽ không chỉ bị các lập trình viên C ++ xa lánh mà còn (đặc biệt) bởi các lập trình viên C. Có những lý do chính đáng để loại bỏ diễn viên trong mã C. Nó không cần thiết và việc thêm nó có thể che giấu lỗi. Vì vậy, hãy coi chúng như hai ngôn ngữ riêng biệt. +1 :)
jalf

26
@BlueRaja Hãy tưởng tượng nếu Guido quyết định không thêm các đối tượng vào ngôn ngữ kịch bản của mình và hai nhóm đã tạo ra các bộ nĩa Python không tương thích lẫn nhau để thêm các đối tượng, một nhóm có mô hình đối tượng dựa trên Smalltalk, nhóm kia có hệ thống lớp dựa trên Simula. Sau đó, Guido tiếp tục cải tiến Python tập trung vào việc sử dụng cốt lõi của nó. Điều đó gần với tình huống C / Objective C / C ++ hơn.
Pete Kirkham

11
@BlueRaja: Chúng là hai ngôn ngữ riêng biệt có chung một lõi chung khá lớn. Nếu bạn lập trình trong cốt lõi chung đó, bạn sẽ gặp khó khăn khi làm những thứ không phải là mã tốt bằng cả hai ngôn ngữ. Chọn một ngôn ngữ để viết bất kỳ chương trình nhất định nào và làm cho nó tốt bằng ngôn ngữ đó.
David Thornley

115

Tôi nhận ra đó không phải là một câu trả lời chuyên nghiệp hay hay cụ thể, nhưng đối với tôi đơn giản là vì tôi thực sự thích C. C nhỏ và đơn giản và tôi có thể phù hợp với toàn bộ ngôn ngữ trong não của mình, C ++ đối với tôi luôn có vẻ như là một mớ hỗn độn lớn. với tất cả các loại lớp, tôi rất khó mò mẫm. Do đó, tôi thấy rằng bất cứ khi nào tôi viết C ++, tôi sẽ dành nhiều thời gian hơn để gỡ lỗi và đập đầu vào các bề mặt cứng so với khi tôi viết mã C. Một lần nữa tôi nhận ra rằng phần lớn điều này là do sự 'thiếu hiểu biết' của chính tôi.

Nếu tôi được chọn, tôi sẽ viết tất cả những thứ cấp cao như giao diện và tương tác cơ sở dữ liệu trong python (hoặc có thể là C #) và tất cả những thứ phải nhanh trong C. Với tôi, điều đó mang lại cho tôi điều tốt nhất trên tất cả các thế giới. Viết mọi thứ bằng C ++ có cảm giác như trở nên tồi tệ nhất trong tất cả các thế giới.

Chỉnh sửa: Tôi muốn nói thêm rằng tôi nghĩ rằng C với một vài tính năng của C ++ phần lớn là một ý tưởng tồi nếu bạn có nhiều người làm việc trong một dự án hoặc nếu khả năng bảo trì là ưu tiên. Sẽ có sự bất đồng về những gì tạo thành một 'một vài' và những bit nào nên được thực hiện trong C và những bit nào trong C ++ cuối cùng dẫn đến một cơ sở mã rất phân liệt.


24
Tôi đã sử dụng C ++ trong vài năm và vẫn dành 50% thời gian để cấu trúc lại mã để trở thành "C ++ đúng". Đó là một cơn ác mộng, như bạn nói.
Kai

12
Bạn luôn có thể làm đúng ngay lần đầu tiên. Thêm const không khó.
GManNickG

14
Tôi đã sử dụng C ++ trong mười năm và quay lại C (đối với các hệ thống nhúng trong trường hợp của tôi) là điều tốt nhất tôi từng làm.
Warren P

Tôi thích câu trả lời này. Bạn cũng đã đóng đinh cảm xúc của tôi. Tôi đã có nhiều năm làm việc với tư cách là một nhà phát triển C ++, công việc hàng ngày của tôi vẫn là C ++. Nhưng điều đó không có nghĩa là tôi giống như ngôn ngữ, tôi thấy vẻ đẹp trong C.
Matt Joiner

10
+1, Do đó tôi thấy rằng bất cứ khi nào tôi viết C ++ Tôi sẽ chi tiêu nhiều thời gian gỡ lỗi và đập đầu tôi chống lại các bề mặt cứng hơn khi tôi mã C . Không thể đồng ý với bạn nhiều hơn. Câu trả lời tốt nhất. :)
ApprenticeHacker

58

Đơn giản là C ++ không được hỗ trợ trong một số môi trường thế giới thực, chẳng hạn như các hệ thống nhúng cấp thấp. Và có một lý do chính đáng cho điều đó: C dễ dàng đủ tốt cho những thứ như vậy, vậy tại sao lại sử dụng thứ lớn hơn?


2
Đúng. Tôi đã thấy trình biên dịch c cho bộ điều khiển vi 8 bit.
dmckee --- cựu điều hành kitten

6
tất nhiên. Ngày nay, hầu hết các chip 8-bit đều có trình biên dịch C.
Eli Bendersky

gbdk.sourceforge.net - GBDK cho một ..
Kelden Cowan

+1 đây là câu trả lời chính xác. Trình biên dịch C ++ khó viết hơn nhiều so với trình biên dịch C, phần lớn là do sự phức tạp của (đa) kế thừa.
BlueRaja - Danny Pflughoeft

9
@BlueRaja: so với các mẫu ... đa kế thừa có thể không phải là yếu tố ngăn cản thực sự ở đây. Sau khi tất cả các mẫu tạo thành một ngôn ngữ chính thức của riêng chúng.
Matthieu M.

49

Tôi ghét lập trình bằng C ++.


6
Lol Tôi thích rằng một
Tamas Czinege

30
Rất thuyết phục! Tôi đang nghĩ đến việc chuyển sang Python dựa trên lập luận của bạn.
Jimmy J

8
Có thể không thuyết phục, nhưng đó là lý do thực sự.
Georg Schölly

@Jimmy J: Python thật không thể tin được. Nó là tốt nhất của Unix, C và tất cả các tính năng ngôn ngữ "hiện đại" của bạn được thực hiện đúng. Nếu bạn gặp vấn đề về hiệu suất, Python muốn bạn chuyển sang C và thực hiện dễ dàng.
Matt Joiner

2
@Georg: Tôi thừa nhận là tôi chưa bao giờ xem qua, tôi rất ấn tượng với Python.
Matt Joiner

38

Một vài lý do có thể là:

  • Thiếu hỗ trợ - Không phải mọi trình biên dịch C cũng là trình biên dịch C ++. Không phải tất cả các trình biên dịch đều đặc biệt tuân thủ tiêu chuẩn, ngay cả khi chúng tuyên bố hỗ trợ C ++. Và một số trình biên dịch C ++ tạo ra mã cồng kềnh và không hiệu quả một cách vô vọng. Một số trình biên dịch có triển khai thư viện chuẩn rất tệ. Việc phát triển chế độ hạt nhân thường không thể sử dụng thư viện chuẩn C ++ cũng như một số tính năng ngôn ngữ. Bạn vẫn có thể viết mã C ++ nếu bạn bám vào cốt lõi của ngôn ngữ, nhưng sau đó chuyển sang C có thể đơn giản hơn.
  • Sự quen thuộc. C ++ là một ngôn ngữ phức tạp. Dạy ai đó về C dễ hơn C ++, và tìm được một lập trình viên C giỏi hơn là một lập trình viên C ++ giỏi. (từ khóa ở đây là "tốt". Có rất nhiều lập trình viên C ++, nhưng hầu hết họ đều chưa học ngôn ngữ này một cách chính xác)
  • Đường cong học tập - Như trên, dạy ai đó C ++ là một nhiệm vụ rất lớn. Nếu bạn đang viết một ứng dụng phải được những người khác duy trì trong tương lai và những người khác này có thể không phải là lập trình viên C ++, thì việc viết nó bằng C sẽ giúp bạn dễ dàng nắm bắt hơn rất nhiều.

Tôi vẫn muốn viết bằng C ++ hơn khi tôi có thể thoát khỏi nó, và nhìn chung, tôi nghĩ lợi ích nhiều hơn bất lợi. Nhưng tôi cũng có thể thấy đối số để sử dụng C trong một số trường hợp.


4
Tôi sẽ nói thêm rằng mã C biên dịch nhanh hơn nhiều so với C ++. Một dự án lớn tại công ty chúng tôi (hơn một triệu dòng) biên dịch chưa đầy 30 giây.
Calmarius

31

Có vô số tranh luận về lập trình nhúng, hiệu suất và những thứ, tôi không mua chúng. C ++ dễ dàng so sánh với C trong những lĩnh vực đó. Tuy nhiên:

Chỉ gần đây sau khi đã lập trình bằng C ++ trong hơn 15 năm, tôi đã khám phá lại nguồn gốc C của mình. Tôi phải nói rằng mặc dù có những tính năng tốt trong C ++ giúp cuộc sống dễ dàng hơn nhưng cũng có vô số cạm bẫy và kiểu "luôn luôn có một cách tốt hơn". Bạn không bao giờ thực sự hài lòng về giải pháp bạn đã làm. (Đừng hiểu sai ý tôi, đây có thể là một điều tốt, nhưng hầu hết là không).

C ++ mang đến cho bạn tiếng súng vô hạn. Điều đó có thể được cho là tốt nhưng bằng cách nào đó bạn luôn sử dụng quá nhiều. Điều này có nghĩa là bạn đang ngụy trang các giải pháp của mình bằng các lớp trừu tượng, tổng quát, v.v. "đẹp" và "đẹp".

Những gì tôi phát hiện ra khi quay lại với C là nó thực sự là một lập trình thú vị trở lại. Đã dành rất nhiều thời gian để lập mô hình và suy nghĩ về cách sử dụng tốt nhất tính kế thừa, tôi thấy rằng lập trình bằng C thực sự làm cho mã nguồn của tôi nhỏ hơn và dễ đọc hơn. Điều này tất nhiên là tùy thuộc vào mức độ kỷ luật của bạn. Nhưng rất dễ đưa quá nhiều trừu tượng vào mã chuyển tiếp, điều này không bao giờ thực sự cần thiết.


8
Không có gì xúc phạm, nhưng nó cũng có thể phụ thuộc vào những gì bạn nghĩ C ++. Tính kế thừa là thứ mà tôi liên tưởng đến Java nhiều hơn C ++, và nếu bạn coi C ++ nghiêm ngặt như một ngôn ngữ OOP hay là Java (C với các lớp), thì tôi đồng ý với bạn. Nếu bạn gắn bó với một hương vị hiện đại hơn của C ++, tôi nghĩ rằng nó thú vị hơn so với C
jalf

11
Tuy nhiên, một lần nữa, tôi không nghĩ C ++ là một ngôn ngữ OO và nó không nên được coi là một. Tôi nghĩ rằng lập trình chung chung là một đặc điểm mạnh mẽ hơn nhiều của C ++. Hầu hết mã C ++ mà tôi thấy không cố gắng đặc biệt để trở thành "OO" hoặc chứa mã không cần thiết. Nó thường gọn gàng hơn so với tương đương mã C
jalf

3
@jalf: Một điều khác mà tôi thấy có thể trở thành sự phân tâm "luôn luôn có một cách tốt hơn" trong C ++ là tổng quát hóa mọi thứ bằng các mẫu. "Có lẽ chúng ta nên để người dùng của lớp này quyết định loại số nguyên cơ bản sẽ sử dụng?" Nhưng có lẽ bạn không cần điều đó, và trong C thì bạn sẽ không bận tâm. Và đôi khi tôi tự nghĩ rằng, "Chúng ta thực sự nên cung cấp một giao diện trình lặp chuyển tiếp cho lớp này", khi trong C, bạn chỉ hiển thị một con trỏ tới phần tử đầu tiên và một số lượng, hoặc (chiều cao của fanciness!) Một hàm lấy một con trỏ hàm gọi lại.
j_random_hacker

2
Tôi thấy việc lùi lại một bước khi viết mã bằng C ++ sẽ giúp ích. Quyết định mục tiêu và viết hướng tới nó (C style). Yếu tố trong các isms C ++ khi tính hữu dụng của chúng trở nên rõ ràng.
Matt Joiner

2
infinite gunfire, ooh yeah, rất đúng. Chân chúng ta theo nghĩa đen run :)
Quetzalcoatl

27

C có ưu điểm chính là bạn chỉ có thể thấy những gì đang thực sự diễn ra khi bạn nhìn vào một số đoạn mã (vâng, bộ tiền xử lý: biên dịch với -E và sau đó bạn sẽ thấy nó). Điều gì đó quá thường xuyên không đúng khi bạn nhìn vào một số mã C ++. Ở đó bạn có các hàm tạo và hàm hủy được gọi ngầm dựa trên phạm vi hoặc do các phép gán, bạn có quá tải toán tử có thể có hành vi đáng ngạc nhiên ngay cả khi nó không bị lạm dụng nhiều. Tôi thừa nhận mình là một người thích kiểm soát, nhưng tôi đã đi đến kết luận rằng đây không phải là một thói quen xấu đối với một nhà phát triển phần mềm, những người muốn viết phần mềm đáng tin cậy. Tôi chỉ muốn có một cơ hội công bằng để nói rằng phần mềm của tôi làm chính xác những gì nó phải làm và đồng thời không có cảm giác tồi tệ trong bụng bởi vì tôi biết vẫn có thể có rất nhiều lỗi trong đó mà tôi sẽ không '

C ++ cũng có các mẫu. Tôi ghét và yêu họ, nhưng nếu ai đó nói rằng họ hoàn toàn hiểu họ, tôi gọi họ là kẻ nói dối! Điều đó bao gồm những người viết trình biên dịch cũng như những người tham gia vào việc xác định tiêu chuẩn (điều này trở nên rõ ràng khi bạn cố gắng đọc nó). Có rất nhiều trường hợp góc gây hiểu lầm vô lý liên quan đến mức không thể xem xét tất cả chúng trong khi bạn viết mã thực tế. Tôi thích các mẫu C ++ vì sức mạnh tuyệt đối của chúng. Thật sự tuyệt vời với những gì bạn có thể làm với chúng, nhưng chúng cũng có thể dẫn đến những lỗi kỳ lạ và khó tìm nhất mà người ta có thể (không) tưởng tượng. Và những lỗi này thực sự xảy ra và thậm chí không hiếm. Đọc về các quy tắc liên quan để giải quyết các mẫu trong C ++ ARM gần như khiến đầu tôi bùng nổ. Và nó mang lại cho tôi cảm giác tồi tệ khi lãng phí thời gian khi phải đọc các thông báo lỗi trình biên dịch dài vài 1000 ký tự mà tôi cần 10 phút trở lên để hiểu trình biên dịch thực sự muốn gì từ tôi. Trong mã C ++ (thư viện) điển hình, bạn cũng thường tìm thấy rất nhiều mã trong các tệp tiêu đề để tạo một số mẫu nhất định có thể thực hiện được, do đó làm cho chu trình biên dịch / thực thi chậm một cách đáng kinh ngạc ngay cả trên các máy nhanh và yêu cầu biên dịch lại các phần lớn của mã khi bạn thay đổi nội dung nào đó. ở đó.

C ++ cũng có bẫy const. Bạn có thể tránh const cho tất cả trừ các trường hợp sử dụng tầm thường nhất hoặc sớm muộn gì bạn cũng phải bỏ nó đi hoặc cấu trúc lại các phần lớn của cơ sở mã khi nó phát triển, đặc biệt là khi bạn sắp phát triển một thiết kế OO đẹp và linh hoạt.

C ++ có khả năng gõ mạnh hơn C, điều này thật tuyệt, nhưng đôi khi tôi cảm thấy như đang ăn Tamagotchi khi tôi cố gắng biên dịch mã C ++. Một phần lớn các cảnh báo và lỗi mà tôi thường nhận được từ nó không thực sự là do tôi làm điều gì đó không hiệu quả, mà chỉ là những thứ mà trình biên dịch không muốn tôi làm theo cách này hoặc không mà không truyền hoặc đặt thêm một số từ khóa ở đây và ở đó.

Đây chỉ là một số lý do tại sao tôi không thích C ++ cho phần mềm mà tôi chỉ viết một mình bằng cách sử dụng một số thư viện bên ngoài được cho là mạnh mẽ. Sự kinh hoàng thực sự bắt đầu khi bạn viết mã theo nhóm với những người khác. Hầu như không quan trọng cho dù họ là những hacker C ++ thông minh hay những người mới bắt đầu ngây thơ. Mọi người đều mắc lỗi, nhưng C ++ làm cho việc cố tình tìm thấy chúng rất khó và thậm chí khó phát hiện chúng trước khi chúng xảy ra.

Với C ++, bạn chỉ đơn giản là bị lạc mà không cần sử dụng trình gỡ lỗi mọi lúc nhưng tôi muốn có thể xác minh tính đúng đắn của mã trong đầu và không phải dựa vào trình gỡ lỗi để tìm mã của tôi đang chạy trên những con đường mà tôi không bao giờ có thể lường trước được. Tôi thực sự cố gắng chạy tất cả mã trong đầu và cố gắng lấy tất cả các nhánh mà nó có, ngay cả trong các chương trình con, v.v. và chỉ thỉnh thoảng sử dụng trình gỡ lỗi chỉ để xem nó chạy qua tất cả những nơi ấm cúng mà tôi đã chuẩn bị cho nó độc đáo như thế nào. Viết và thực thi rất nhiều trường hợp thử nghiệm đến mức tất cả các đường dẫn mã đã được sử dụng trong tất cả các kết hợp với tất cả các loại dữ liệu đầu vào kỳ lạ đơn giản là không thể. Vì vậy, bạn có thể không biết về các lỗi trong chương trình C ++ nhưng không có nghĩa là chúng không có ở đó. Các dự án C ++ càng lớn thì càng khiến tôi tự tin rằng nó sẽ không có nhiều lỗi không bị phát hiện ngay cả khi nó chạy hoàn hảo với tất cả dữ liệu thử nghiệm mà chúng tôi có trong tay. Cuối cùng, tôi dọn nó đi và bắt đầu lại với một số ngôn ngữ khác hoặc sự kết hợp của các ngôn ngữ khác.

Tôi có thể đi tiếp nhưng tôi đoán rằng tôi đã nói rõ quan điểm của mình vào lúc này. Tất cả những điều này đã khiến tôi cảm thấy không hiệu quả khi tôi lập trình bằng C ++ và khiến tôi mất tự tin vào tính đúng đắn của mã của chính mình, nghĩa là tôi sẽ không sử dụng nó nữa, trong khi tôi vẫn sử dụng và dựa vào mã C mà tôi đã viết hơn 20 nhiều năm trước. Có thể chỉ đơn giản là vì tôi không phải là một lập trình viên C ++ giỏi, hoặc có thể khá giỏi về C và các ngôn ngữ khác cho phép tôi nhận ra tôi thực sự là một người giỏi như thế nào khi nói đến C ++ và tôi sẽ không bao giờ có thể hiểu hết được nó. .

Cuộc sống thật ngắn ngủi ...


2
+1, không thể đồng ý hơn.
missfaktor

2
Điều này có vẻ song song với lập luận của Linus. (Ít của một bối cảnh đối tượng = dễ hiểu hơn.)
Warren P

20

Trong môi trường nhúng cấp thấp, một số "kỹ sư phần mềm" sẽ có nền tảng EE và hầu như chưa thành thạo C. C ++ phức tạp hơn và một số trong số này chỉ đơn giản là ngại học một ngôn ngữ mới. Do đó C được dùng làm mẫu số chung nhỏ nhất. (Trước khi bạn đề nghị loại bỏ những kẻ này, chúng ít nhất cũng quan trọng như những chuyên gia CS, những người không hiểu những thứ tương tự khó khăn.)

Nói từ kinh nghiệm đã kế thừa và duy trì cả hai: một thiết kế khủng khiếp trong C rất khó hiểu, rút ​​ngắn và cấu trúc lại thành một thứ có thể sử dụng được.

Một thiết kế khủng khiếp trong C ++ còn tệ hơn vô cùng khi các lớp trừu tượng ngẫu nhiên gửi màn hình não của bạn xung quanh cơ sở mã cố gắng tìm ra mã nào sẽ được thực thi trong trường hợp nào.

Nếu tôi phải làm việc với những kỹ sư mà tôi biết sẽ không tạo ra những thiết kế tuyệt vời, tôi muốn có cái trước hơn là cái sau.


Amen, anh trai. Đã từng làm việc với mã nguồn C do các kỹ sư phần cứng tạo ra, tôi rùng mình khi nghĩ đến những gì tôi sẽ phải đối mặt nếu họ làm điều đó trong C ++.
Richard Chambers

19

Tôi không thấy lý do nào khác ngoài sự không thích cá nhân, ngay cả đối với việc lập trình hệ thống nhúng và những thứ tương tự. Trong C ++, bạn chỉ trả phí cho các tính năng bạn sử dụng. Bạn có thể sử dụng tập con C của C ++ trong một số trường hợp cụ thể khi chi phí C ++ quá cao đối với bạn. Điều này nói rằng, tôi nghĩ rằng một số lập trình viên C đánh giá quá cao chi phí của một số cấu trúc C ++. Hãy để tôi liệt kê một số ví dụ:

  • Các lớp và hàm thành viên có chi phí bằng không so với các hàm thông thường (trừ khi bạn sử dụng các hàm ảo, trong trường hợp này không có chi phí so với việc sử dụng con trỏ hàm)
  • Các mẫu có rất ít chi phí (hầu hết thường không có chi phí nào cả)

Một lý do hợp lệ là khi bạn đang lập trình cho một nền tảng không có trình biên dịch C ++ phù hợp (không có trình biên dịch C ++ nào cả, hoặc trình biên dịch tồn tại, nhưng được triển khai kém và áp đặt chi phí cao không cần thiết cho một số tính năng C ++).


3
Một lớp với các hàm ảo có nhiều chi phí hơn: mỗi cá thể phải mang theo một trường bổ sung để xác định kiểu.
bstpierre

6
Chi phí nhiều hơn những gì? Loại được mang trong vtbl. Nếu bạn triển khai cơ chế tương tự bằng cách sử dụng con trỏ hàm, bạn cần ít nhất một con trỏ (hoặc chỉ mục, hoặc bất cứ thứ gì) để chọn con trỏ hàm bạn muốn được sử dụng.
Suma

3
bstpierre: Tôi nghĩ rằng những gì Suma được nói là: rằng nó không có nhiều chi phí so với việc thực hiện các tính năng bằng tay mình trong C.
Martin York

2
Một con trỏ đến các lớp vtable được lưu trữ trong mỗi phiên bản của lớp.
tstenner

5
Có một khoản chi phí, nhưng ý tôi là nếu bạn muốn bất kỳ độ phân giải loại động nào, bạn cần một số bộ nhớ để xác định loại, ngay cả trong C. Nếu bạn không muốn các loại động, bạn không cần phải trả chi phí ( không sử dụng các chức năng ảo nếu bạn không cần chúng).
Suma

13

Tại sao hạn chế nói tiếng Anh? Có lẽ bạn sẽ là một tác giả sáng tạo hơn bằng tiếng Serbia.

Lập luận tương tự, với những ngụy biện rõ ràng. Nếu bạn có một nhiệm vụ và các công cụ tiện nghi của bạn giải quyết công việc một cách hiệu quả, bạn có thể sẽ sử dụng các công cụ thoải mái của mình vì lý do chính đáng.


3
Nếu tôi nói thông thạo cả tiếng Anh và tiếng Serbia trôi chảy, tôi chắc chắn rằng tôi sẽ sáng tạo hơn. Bạn không đồng ý?

2
@Neil thực sự, nhưng nỗ lực cần thiết để học tiếng Serbia có thể không hợp lý để giải quyết khối sáng tạo hiện tại của tôi.
slim

2
Tôi nghĩ Arno đang làm nổi bật sự thật rằng bạn không viết cho CPU, bạn đang viết cho đồng nghiệp của bạn đọc và các thư viện khác của bạn để liên kết, v.v. Rốt cuộc, nếu tôi chỉ muốn biểu đạt và tốc độ, tôi sẽ viết bằng OCaml.
Ken

10

C ++ có một đường cong học tập dài hơn nhiều. C chỉ có một số cấu trúc bạn cần biết và sau đó bạn có thể bắt đầu viết mã phần mềm mạnh mẽ. Trong C ++, bạn cần học cơ sở C, sau đó là lập trình OO và lập trình chung, ngoại lệ, v.v. Và sau một thời gian, bạn có thể biết hầu hết các tính năng và có thể sử dụng chúng một cách rõ ràng, nhưng bạn vẫn không biết trình biên dịch sẽ như thế nào dịch chúng, những chi phí tiềm ẩn mà chúng có hay không. Điều này tốn nhiều thời gian và năng lượng.

Đối với một dự án chuyên nghiệp, lập luận này có thể không được tính, vì bạn có thể tuyển dụng những người đã biết rất rõ về C ++. Nhưng trong các Dự án mã nguồn mở, nơi C vẫn còn được sử dụng nhiều, mọi người chọn ngôn ngữ họ thích và họ có thể sử dụng. Hãy xem xét rằng không phải mọi lập trình viên hệ điều hành đều là lập trình viên chuyên nghiệp.


1
Ờ ... không? Bạn tìm hiểu cơ sở C (có thể ngoại trừ mảng và xử lý chuỗi kiểu C được bỏ qua cho <vector> và <string>), và bạn sẽ bắt đầu. Bạn có thể chọn mọi thứ khác khi bạn tiếp tục. Bạn không cần phải biết gì về OO, GP, hoặc trường hợp ngoại lệ để bắt đầu với C ++ ...
DevSolar

4
C có thể "nhỏ hơn" nhưng về lâu dài nó không dễ sử dụng hơn. Quản lý bộ nhớ thủ công? Không, cám ơn.
Jimmy J

7
Không có cái gọi là quản lý bộ nhớ tự động trong C ++.
Warren P

3
C ++ không giải quyết được vấn đề quản lý bộ nhớ. Ngay khi bạn nghĩ rằng bạn có một xử lý trên con trỏ, C ++ đi và thêm một mô hình ngoại lệ khủng khiếp. Đến vùng đất C99, Ngoại trừ cấu trúc dữ liệu, tôi khá chắc chắn rằng mình hầu như không chạm vào malloc. Thậm chí sau đó tôi có thể "gói gọn" một số ít các cuộc gọi malloc. Đó là câu chuyện tương tự trong C ++ (quản lý bộ nhớ ngầm, chỉ được thực hiện trên heap thay vì ngăn xếp), chỉ với tất cả nhạc jazz con trỏ thông minh.
Matt Joiner

1
@ereOn: Đó là sự thật, nhận xét như tôi đã viết 3 năm trước không còn giữ được nữa. :)
Matt Joiner

10

Tôi muốn theo dõi câu trả lời của Dan Olson. Tôi tin rằng mọi người lo sợ các tính năng nguy hiểm tiềm ẩn và phản tác dụng của C ++, và chính đáng là như vậy. Nhưng không giống như những gì Dan nói, tôi không nghĩ rằng chỉ cần quyết định một tiêu chuẩn mã hóa là có hiệu quả, vì hai lý do:

  1. Các tiêu chuẩn mã hóa có thể khó thực thi nghiêm ngặt
  2. Có thể rất khó để tìm ra một cái hay.

Tôi nghĩ rằng lý do thứ hai ở đây quan trọng hơn nhiều so với lý do thứ nhất, bởi vì quyết định về một tiêu chuẩn mã hóa có thể dễ dàng trở thành một vấn đề chính trị và có thể được sửa đổi sau này. Hãy xem xét trường hợp đơn giản sau:

  1. Bạn được phép sử dụng vùng chứa stl, nhưng không được phép sử dụng các mẫu trong bất kỳ mã nào của riêng bạn.
  2. Mọi người bắt đầu phàn nàn rằng họ sẽ làm việc hiệu quả hơn nếu họ chỉ được phép viết mã lớp mẫu này hoặc lớp mẫu kia.
  3. Tiêu chuẩn mã hóa được sửa đổi để cho phép điều đó.
  4. Trượt dốc đến một tiêu chuẩn mã hóa quá phức tạp mà không ai tuân theo và sử dụng chính xác loại mã nguy hiểm mà tiêu chuẩn được cho là phải ngăn chặn, kết hợp với sự quan liêu quá mức xung quanh tiêu chuẩn.

(Phương án thay thế mà tiêu chuẩn không được sửa đổi ở bước 3 theo kinh nghiệm là quá khó để xem xét và dù sao cũng sẽ không tốt hơn nhiều.)

Mặc dù tôi đã từng sử dụng C ++ cho mọi thứ cách đây vài năm, nhưng tôi bắt đầu cảm thấy mạnh mẽ rằng C thích hợp hơn trong các tác vụ cấp thấp cần được xử lý bởi C hoặc C ++ và mọi thứ khác nên được thực hiện trong một số tác vụ khác ngôn ngữ hoàn toàn. (Chỉ những trường hợp ngoại lệ có thể xảy ra là một số miền có vấn đề hiệu suất cao cụ thể, wrt. Blitz ++ )


10

Tôi sử dụng C, hoặc ít nhất là xuất giao diện C khi tôi viết mã thư viện.

Tôi không muốn ABI phức tạp không rõ ràng.


Tương tự. Chỉ nghiêm ngặt C trong giao diện. Điều cuối cùng tôi muốn là khuôn khổ đối tượng lố bịch của người khác đẩy lên tôi.
Matt Joiner

9

Tôi chưa bao giờ thấy bất kỳ lập luận nào về việc sử dụng C thay vì C ++ mà tôi cho là thuyết phục. Tôi nghĩ rằng hầu hết mọi người đều sợ một số tính năng mà C ++ cung cấp, thường là chính đáng. Tuy nhiên, điều này không thuyết phục tôi bởi vì người ta có thể thực thi xem có sử dụng các tính năng nhất định hay không thông qua các tiêu chuẩn mã hóa. Ngay cả trong C, có nhiều điều bạn muốn tránh. Loại bỏ hoàn toàn C ++ về cơ bản là nói rằng nó không mang lại lợi ích cụ thể nào so với C mà sẽ giúp người ta viết mã tốt hơn, đó là một quan điểm mà tôi cho là khá thiếu hiểu biết.

Ngoài ra, mọi người dường như luôn đặt ra vấn đề về các nền tảng không có trình biên dịch C ++ nào tồn tại. Chắc chắn C sẽ thích hợp ở đây, nhưng tôi nghĩ bạn sẽ khó tìm được một nền tảng như vậy vào những ngày này.


3
Đồng ý rằng "C tốt hơn C ++" không bao giờ đứng trước sự soi xét.
Jimmy J

6
Tôi tin rằng C ++ mang lại cho tôi RẤT ÍT lợi ích, và CHI PHÍ cho tôi một lượng lớn sự phức tạp ngẫu nhiên. Tôi tin rằng sẽ mất khoảng 1500 trang sách giáo khoa C ++ và mười năm nỗ lực, để trở nên thành thạo C ++ như tôi hiện tại về C, Pascal, Python và Objective-C. Mỗi ngôn ngữ ở trên trực giao hơn khoảng 20 lần, nhỏ gọn và thuận tiện hơn về mặt tinh thần để sử dụng, chưa kể là mạnh mẽ hơn, trong môi trường tôi sử dụng chúng. Đơn giản là KHÔNG có cách sử dụng hợp lý hợp lý nào cho C ++ trong môi trường phát triển thông thường của tôi.
Warren P

@Warren Bạn chỉ trả tiền cho những gì bạn sử dụng, giống như bất kỳ ngôn ngữ nào. Nếu bạn không có khả năng quyết định cách viết mã khôn ngoan trong C ++ thì đó là do bạn, không phải ngôn ngữ.
Dan Olson

2
Không phải vậy. Nếu bạn là nhà phát triển duy nhất trong một dự án, điều đó có thể là như vậy. Nhưng ngay sau khi chúng tôi có hai nhà phát triển, chúng tôi có những trận chiến. Gì? Bạn nhấn mạnh vào vùng chứa IoC, trong khi tôi thích một số cách khác để làm ủy quyền ... Bạn thích ba cấp độ của các mẫu lồng nhau và tôi thích mẫu không. Một mớ hỗn độn.
Warren P

Tôi biết bài viết này đã 10 năm tuổi nhưng liệu có thực sự công bằng khi so sánh C và C ++ nữa không? Cả hai đều là các ngôn ngữ riêng biệt, khác nhau (kể từ C99) và cả hai đều có những lợi ích và nhược điểm mà mỗi ngôn ngữ đều bao gồm. C ++ khó gỡ lỗi và bảo trì? Tính rõ ràng của C cho phép bạn gỡ lỗi tốt hơn. C không có thuốc chung? C ++ có chung chung! Tại thời điểm này, không có ngôn ngữ nào tốt hơn ngôn ngữ kia.
Nergal

9

Một điểm mà tôi chưa thấy được nêu ra, mà tôi nghĩ là quan trọng nhất:

Hầu hết các thư viện tôi sử dụng hàng ngày là thư viện C với các liên kết cho Python, Ruby, Perl, Java, v.v. Từ những gì tôi đã thấy, việc bọc các thư viện C với 19 liên kết ngôn ngữ khác nhau dễ dàng hơn rất nhiều so với bọc các thư viện C ++.

Ví dụ, tôi đã học Cairo một lần và từ đó đã sử dụng nó trong 3 hoặc 4 ngôn ngữ khác nhau. Chiến thắng lớn! Tôi muốn viết một chương trình có thể được sử dụng lại trong tương lai, và viết một chương trình có thể dễ dàng được áp dụng cho các ngôn ngữ lập trình khác là một trường hợp cực kỳ nghiêm trọng.

Tôi biết có thể liên kết các thư viện C ++, nhưng AFAICT thì không giống như vậy. Tôi đã sử dụng Qt (v3 và v4) trong các ngôn ngữ khác và nó không ở đâu tốt để sử dụng: họ cảm thấy giống như viết C ++ bằng một số ngôn ngữ khác, không giống như các thư viện bản địa. (Bạn phải chuyển các dấu hiệu của phương thức C ++ dưới dạng chuỗi!)

C ++ có lẽ là một ngôn ngữ tốt hơn nếu bạn đang viết một hàm để sử dụng một lần hoặc nếu bạn nghĩ rằng tất cả thế giới là C ++. C có vẻ như là một ngôn ngữ dễ dàng hơn nếu bạn đang thiết kế cho ngôn ngữ khả chuyển ngay từ đầu.


Các phương thức "truyền dưới dạng chuỗi!" đó là một khiếm khuyết của Qt, không phải C ++. Bạn thực sự có thể có cùng một cơ chế ngu ngốc với một framework C mà bạn muốn. Ngay cả những người ở Qt cũng đồng ý rằng làm điều đó là một sai lầm. Chỉ là không có giải pháp thay thế nào tốt hơn trong tâm trí họ vào thời điểm đó và đã quá muộn để thay đổi nó khi họ nhận ra.
vào

7

Phát triển nhân Windows không hỗ trợ c ++ (đáng buồn là).


Làm như thế nào? Tại sao? Nhị phân được tạo ra từ trình biên dịch C ++ có khác với trình biên dịch C không? Không phải phát triển trình điều khiển chỉ đơn giản là tuân theo API?
Dave Van den Eynde

4
Bởi vì rất nhiều tính năng C ++ yêu cầu hỗ trợ thời gian chạy, điều này có thể không nhỏ để triển khai ở chế độ hạt nhân. Đối với một điều, các chức năng cấp phát bộ nhớ khác nhau được sử dụng, vì vậy các phần của thư viện chuẩn sẽ phải được thay thế. Các trường hợp ngoại lệ nói chung cũng tệ.
jalf

3
Tôi sẽ nói thêm rằng Linux Torvalds may mắn thay đã đốt cháy bất kỳ cơ hội nào của C ++ trong Linux vì nhiều lý do hơn là ngoại lệ. Đã có một số hệ điều hành bằng các ngôn ngữ khác: Java, C ++, trình hợp dịch. Chỉ có những người lắp ráp đã tồn tại với cách sử dụng hợp lý.
Matt Joiner


Lưu ý rằng nó dành cho Visual Studio 2015?
LegendLength

6

Bạn có thể đọc một câu nói thú vị về lý do Linus Torvalds ủng hộ C tại đây


6
Đó là một xu hướng nửa chặt chẽ chống lại thiết kế hướng đối tượng hơn là một xu hướng chống lại C ++.
Dan Olson

16
Mr Torvalds có một danh sách dài những thứ mà anh ấy không thích, C ++, emacs, Subversion, OO để đề cập đến một vài thứ. Đôi khi người ta ước anh ấy sẽ nút môi nhiều hơn một chút

11
Linus thích nói tục và cố gắng khiêu khích và làm mọi người khó chịu. Thật không may, anh ta không thèm học C ++ trước khi tuyên bố rằng nó tệ. Thật không may, những người theo giáo phái của anh ấy tin rằng mọi thứ anh ấy nói phải là sự thật.
jalf

9
Các liên kết được nhiều hơn cho giải trí hơn giáo dục
Paul Dixon

6
Bằng chứng rằng ngay cả những thiên tài đôi khi cũng có thể là những kẻ chết tiệt.
Kaz Dragon

5

Mã gốc trên mac là mục tiêu-c. Mã gốc trên PC là c (window.h) hoặc c ++ (mfc). Cả hai môi trường này sẽ cho phép bạn sử dụng c với ít hoặc không có thay đổi. Khi tôi muốn một thư viện mã được đa nền tảng, ansi c có vẻ là một lựa chọn tốt.


4

Tôi có thể nghĩ ra một số lý do.

Có thể không có trình biên dịch C ++ đạt yêu cầu. C ++ là một ngôn ngữ lớn hơn nhiều và tôi đã chạy các trình biên dịch C trên các hệ thống không thể xử lý C ++ hiện đại.

Người hỏi, hoặc những người mà họ làm việc cùng, có thể quen thuộc với C nhưng không quen thuộc với C ++.

Dự án có thể ở C. Mặc dù có thể thêm một số tính năng C ++ vào C, nhưng điều đó có thể dễ dàng dẫn đến một mớ hỗn độn không thể giải thích được. Tôi khuyên bạn nên chọn ngôn ngữ này hoặc ngôn ngữ kia (thường là C ++, khi thực tế).

Người hỏi có thể có cái nhìn lỗi thời về đường cong học tập của C ++. (Khi tiếp cận đúng cách, nó dễ dàng hơn so với C. Hầu hết các sách giới thiệu mà tôi đã xem đều không tiếp cận đúng cách.)

Hãy nhớ rằng C và C ++ là hai ngôn ngữ khác nhau và ngày càng khác nhau theo thời gian. Viết mã cả hai cùng một lúc là một ý tưởng tồi và việc sử dụng một tập hợp con giống C của C ++ sẽ bỏ lỡ hầu hết các ưu điểm của C ++.


3

Nếu bạn làm việc trong môi trường có hai ngôn ngữ, bạn có thể sử dụng C cho một số chức năng cấp thấp quan trọng về hiệu suất và ngôn ngữ cấp cao / chức năng hơn như C # / Java cho logic nghiệp vụ. Nếu mã C ++ được sử dụng cho các chức năng này, thì C-Wrappers được yêu cầu cho JNI / mã không được quản lý xung quanh và điều này làm cho mọi thứ trở nên phức tạp hơn so với chỉ sử dụng C.


3

Tôi sử dụng C ++ với lập trình C vì hai lý do:

  • vectorstringđể giúp tôi quản lý bộ nhớ mảng
  • kiểm tra loại nghiêm ngặt và casts để cảnh báo và / hoặc bắt tất cả những phiền toái mà tôi sẽ bỏ lỡ nếu không.

Vì vậy, nó là C thực sự vay mượn một vài c ++ nhưng sử dụng trình biên dịch c ++ nhiều nhất có thể. Như ai đó đã nói trong các câu trả lời, tôi thấy bây giờ tôi thực sự đang chọn nhiều C ++ hơn theo cách này và nơi C sẽ liên quan quá nhiều, tôi sử dụng C ++. Màn hình / Khóa bằng cách sử dụng RAII là một trong những cách tôi đã sử dụng gần đây khi xử lý các chương trình đa luồng và một cấu trúc tương tự khác để mở / đóng tệp.


3

Tôi nghĩ rằng C là di động hơn. Tôi đã làm một số công việc khoảng 5 năm trước khi chuyển mã sang nhiều phiên bản unix (AIX, Irix, HPUX, Linux). Mã C rất dễ chuyển nhưng chúng tôi gặp nhiều vấn đề khác nhau khi chuyển một số mã C ++ qua. Có thể đó chỉ là các môi trường phát triển chưa trưởng thành nhưng tôi muốn sử dụng C hơn C ++ vì lý do này ...


1
Mười lăm năm trước, tôi là nhà phát triển chính cho một dự án C ++ nhắm mục tiêu HPUX, AIX và Solaris. Chúng tôi gặp rất ít vấn đề về tính di động của C ++ - hầu như tất cả những vấn đề chúng tôi gặp phải là với sự không tương thích của lệnh gọi hệ thống C.

1
Cách đây chưa đầy mười năm, tôi đã thực hiện một dự án sử dụng HPUX, Solaris và Tru64, sử dụng các trình biên dịch truyền thống. Đêm của chúng tôi không bao giờ được xây dựng. Khi chúng tôi thêm AIX, chúng tôi quyết định chuyển sang C ++ tiêu chuẩn.
David Thornley

Có lẽ những người viết mã của bạn là lập trình viên tốt hơn so với các crap tôi đã phải đối phó với :-)
Gordon Thompson

3
  1. C là một ngôn ngữ đơn giản, C ++ thì không. Đối với nhiều người, C ++ đơn giản là quá phức tạp để có thể thành thạo hoàn toàn, hãy xem tại http://en.wikipedia.org/wiki/C%2B%2B#Criticism .

  2. Vì sự phức tạp, các lập trình viên khác nhau thường chỉ nắm vững các tập con khác nhau của ngôn ngữ. Nó làm cho việc đọc mã của người khác trở nên đau đớn.

  3. Sự phức tạp, cạm bẫy của ngôn ngữ khiến quá nhiều người phân tâm, và đôi khi làm ảnh hưởng đến năng suất. Thay vì tập trung vào công việc, tôi thường thấy mình phải đấu tranh với chính ngôn ngữ. Java / python là những lựa chọn thay thế hiệu quả hơn.

  4. Gỡ lỗi mã C bị hỏng thường đơn giản hơn nhiều so với gỡ lỗi mã C ++ bị hỏng.

  5. Không giống như Java / C #, thư viện chuẩn C ++ đạt được một chút vượt ra ngoài phạm vi của thư viện chuẩn C.

  6. Một số lập trình viên nổi tiếng như Linus Torvalds (Linux) và Richard Stallman (Emacs) không thích C ++.


3
Tôi đã cân nhắc bỏ phiếu cho câu trả lời của bạn chỉ cho đến khi tôi đọc lập luận số 6.
fuz

1

Hầu hết các lập trình viên đều coi chất lượng là ưu tiên hàng đầu. Không phải lúc nào cũng vậy. Nếu bạn đang sử dụng C, thì C ++ có vẻ như nó đang làm quá nhiều thứ cho bạn. Tính nghiêm ngặt của việc kiểm tra kiểu trong C ++ cũng có vẻ hạn chế. Nhiều người sẵn sàng mạo hiểm đưa ra các loại lỗi mà C ++ có thể giúp ngăn chặn để tránh những "phiền toái" này.


1
Hmm, lý do tôi chuyển từ C sang C ++ (cách đây đã lâu) là để kiểm tra kiểu chặt chẽ hơn. Tôi muốn trình biên dịch tìm ra lỗi của mình hơn là người dùng gặp phải lỗi lõi.

1

Có ba lý do tôi có thể nghĩ ra. Một là C phù hợp hơn với các hệ thống nhúng, do kích thước nhỏ của các tệp nhị phân của nó và tính khả dụng rộng rãi hơn của các trình biên dịch C trên bất kỳ hệ thống nào. Thứ hai là tính di động: C là một ngôn ngữ nhỏ hơn và mã ANSI C sẽ được biên dịch ở bất kỳ đâu. Thật dễ dàng hơn để phá vỡ tính di động trong C ++. Điều cuối cùng là ngôn ngữ của chính nó. C ++ khó hơn và chắc chắn là một ngôn ngữ được thiết kế rất kém. Lưới Torvalds được báo cáo ở trên. Bạn cũng có thể muốn xem các Câu trả lời Thường gặp trong C ++ ( http://yosefk.com/c++fqa/ ).


5
Và, nếu bạn thông minh, sau khi nhìn vào FQA, bạn sẽ nhận ra đó là một công việc hack bởi một người không thực sự hiểu C ++ nhưng dù sao cũng ghét nó.
David Thornley

1

Tính di động có thể là một vấn đề. Khác với câu trả lời của Gordon Carpenter-Thomp, tôi đề nghị rằng đó là sự hỗ trợ thời gian chạy của các phiên bản libstdc ++ khác nhau trên các phiên bản linux / unix khác nhau. Xem liên kết này để có một cuộc thảo luận tốt về điều này. Một đoạn trích nhỏ:

Mã hỗ trợ thời gian chạy được sử dụng bởi các phần khác nhau của ứng dụng C ++ cần phải tương thích. Nếu một phần của chương trình cần dynamic_cast hoặc bắt các đối tượng do phần khác cung cấp, thì cả hai phần phải thống nhất về các chi tiết triển khai nhất định: cách tìm vtables, cách giải phóng ngăn xếp, v.v.

Đối với C ++ và một số ngôn ngữ được GCC hỗ trợ khác có các tính năng tương tự, các chi tiết như vậy được chỉ định bởi C ++ ABI. Bất cứ khi nào ABI được GCC sử dụng thay đổi, bạn sẽ kết thúc với các thư viện không tương thích được tạo bởi các phiên bản GCC khác nhau. Điều này cũng đúng với C đơn giản, nhưng C ABI đơn giản hơn nhiều và tồn tại lâu hơn nên nó khá ổn định.


1

Tôi có thể làm theo nhiều gợi ý ở đây theo cả hai hướng. Nhưng cuối cùng nó đi đến a) đơn giản có thể so sánh được b) phức tạp có thể so sánh được.

Tôi không biết ai đó đã "phát minh" ra một loại phép đo độ phức tạp của ngôn ngữ.

Trên thang điểm từ 0 - 10, tôi có thể sẽ đánh giá C ở mức 2 hoặc 3 trong khi C ++ sẽ là từ 8-10. Tôi cho rằng C ++ là một trong những ngôn ngữ phức tạp nhất nhưng tôi không biết ví dụ như Ada, PL1 hoặc tương tự, vì vậy có lẽ nó không phức tạp như vậy so với một số ngôn ngữ khác.

C ++ kế thừa tất cả độ phức tạp của C nên nó không thể thấp hơn mức độ phức tạp của C.

Về phần mình, tôi sẽ cảm thấy thoải mái hơn nhiều khi sử dụng một số ngôn ngữ kịch bản và C. Vì vậy, cuối cùng người ta phải trả lời câu hỏi sau. "Nhiều hơn luôn luôn tốt hơn?"


1

Điều hữu ích nhất mà tôi tìm thấy trong C là thiếu không gian tên và quá tải: tên hàm và ký hiệu là những định danh duy nhất. Để tìm những nơi mà các ký hiệu này được sử dụng, bạn chỉ cần grepthông qua các tệp mã nguồn và kết quả tìm kiếm sẽ hiển thị các vị trí.

Điều cần thiết khi đấu nối một tính năng hoặc thành phần mới vào một hệ thống cũ và rối.

Bạn không thể làm điều này dễ dàng trong C ++, nếu không có công cụ xây dựng đồ thị cuộc gọi phức tạp.


0

Hầu hết mọi người dường như nghĩ rằng C và C ++ có liên quan bằng cách nào đó, nhưng đáng buồn là họ đã nhầm lẫn. C ++ là một ngôn ngữ hoàn toàn khác với C.

Trong C ++, bạn nghĩ về các đối tượng và cách chúng liên quan với nhau. Trong C, bạn nghĩ về API. Nó giống như sự khác biệt giữa ngày và 17.

Một phép tương tự kém: nếu ai đó thêm tiếng Trung vào tiếng Anh và gọi nó là tiếng Anh ++, có lẽ bạn sẽ không cảm thấy thoải mái khi thêm một dòng tiếng Trung vào bức thư tình mới nhất của mình, bởi vì việc thể hiện tình yêu trong phần này của tiếng Anh ++ sẽ dễ dàng hơn nhiều.


0

Sau đây là tất cả các lý do tại sao có thể có lợi khi giới hạn một dự án ở C:

  • biên dịch nhanh hơn vì ngôn ngữ đơn giản hơn nhiều
  • yêu cầu ít hỗ trợ thời gian chạy hơn, làm cho nó phù hợp hơn với môi trường cấp thấp
  • giao diện với các ngôn ngữ khác dễ dàng hơn nhiều
  • hỗ trợ các mảng có kích thước thay đổi trên ngăn xếp
  • dễ đọc mã lắp ráp hơn vì không có sự xáo trộn tên
  • cho phép dễ dàng kết hợp mã do các trình biên dịch khác nhau tạo ra vì nó là giao diện nhị phân ứng dụng tiêu chuẩn trên thực tế
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.