Ngôn ngữ lập trình C vẫn được sử dụng?


96

Tôi là một lập trình viên C # và hầu hết sự phát triển của tôi là dành cho các trang web cùng với một vài ứng dụng Windows. Theo như C đi, tôi đã không sử dụng nó trong một thời gian dài, vì không cần thiết. Tôi rất ngạc nhiên khi một trong những người bạn của tôi nói rằng cô ấy cần học C để thử việc, trong khi tôi đang giúp cô ấy học C #.

Tôi hình dung rằng ai đó sẽ chỉ học C để thử nghiệm nếu có sự phát triển đang được thực hiện trong C. Theo hiểu biết của tôi, tất cả sự phát triển liên quan đến COM và thiết kế phần cứng cũng được thực hiện trong C ++. Do đó, học C không có ý nghĩa nếu bạn cần sử dụng C ++. Tôi cũng không tin vào ý nghĩa lịch sử, vậy tại sao lại lãng phí thời gian và tiền bạc vào việc học C?

C vẫn được sử dụng trong bất kỳ loại phát triển phần mềm mới hay bất cứ điều gì khác?


46
Bạn đã bao giờ thấy một trình biên dịch C ++ cho PIC chưa?
SK-logic

195
Tôi có phải là người duy nhất buồn khi ai đó đánh đồng việc học với việc lãng phí thời gian và tiền bạc không?
Jetti

37
" Theo hiểu biết của tôi, tất cả sự phát triển liên quan đến COM và thiết kế phần cứng cũng được thực hiện trong C ++ " - Âm thanh với tôi như bạn không thực sự làm bất kỳ thiết kế giao diện phần cứng nào.
Ed S.

32
Mọi người quên rằng các ngôn ngữ cấp cao hơn mà chúng ta yêu thích thường được triển khai trong C.
David Cowden

13
@ThomasEding Ngôn ngữ chết? Bạn chắc chắn có kiến ​​thức rất hạn chế về ngôn ngữ lập trình nếu bạn coi C là ngôn ngữ chết.
JesperE

Câu trả lời:


214

C có lợi thế là ngôn ngữ tương đối nhỏ , giúp dễ dàng thực hiện trình biên dịch C (trong khi trình biên dịch C ++ là một con quái vật để viết) và giúp việc học ngôn ngữ này dễ dàng hơn . Cũng xem chỉ số TIOBE , theo đó C hơi đi trước C ++.

Theo thứ tự giảm dần (IMO), C vẫn được sử dụng rất nhiều cho

  • Công cụ nhúng
    Việc chuyển trình biên dịch C sang nền tảng nhỏ dễ dàng hơn so với chuyển trình biên dịch C ++. Ngoài ra, những người ủng hộ C cho rằng C ++ "làm quá nhiều sau lưng họ". Tuy nhiên, IMO đó là FUD.

  • Lập trình hệ thống
    Một lần nữa, điều đó thường là do tuyên bố rằng "dễ dàng hơn để biết trình biên dịch đang làm gì". Tuy nhiên, nhiều chương trình nhúng sẽ được hưởng lợi từ, ví dụ, các mẫu và các tính năng chính khác của C ++.


  • Mặc dù vậy, phần mềm nguồn mở Đó hầu như là một vấn đề về thái độ: OSS luôn ưu tiên C hơn C ++ (trong khi đó ngược lại ở các phần lớn của ngành công nghiệp). Sự căm ghét phi lý của Torvalds thực sự có thể là lý do quan trọng nhất cho điều này trên Linux .


16
Đó là lịch sử nhiều hơn là thái độ. Nhiều trong số những gì bạn có thể xem xét các gói nguồn mở "cốt lõi" ban đầu được phát triển khi C ++ không có sẵn rộng rãi như hiện tại và tài nguyên vẫn còn khan hiếm.
Blrfl

65
Chỉ số TIOBE là một trò đùa. Công cụ tìm kiếm lượt truy cập là vô nghĩa.
DeadMG

29
@Sedate: Các mẫu đó thường gây ra sự phình to mã là một huyền thoại, xuất phát từ thời của trình biên dịch C ++ cổ đại. Trình biên dịch hiện đại sẽ gấp các trường hợp mẫu giống hệt nhau. OTOH, các mẫu cho phép lập trình meta mẫu, thực thi mã tại thời gian biên dịch, thay vì thời gian chạy, dẫn đến việc tạo ra íthơn . Ngoài ra, chúng làm cho các chương trình an toàn hơn nhiều (ít truyền), một thứ thường rất quan trọng trong miền nhúng. Các chuyên gia C ++ đã bị các chuyên gia C ++ đánh bại đến chết (trong số những thứ khác) về sự ngu ngốc của việc ném ra các mẫu.
sbi

18
@James: Ý bạn là những thứ như trừu tượng hiệu quả, lập trình chung và an toàn kiểu? Vâng, ai muốn điều đó.
Xèo

11
@JesperE Khi điều đó xảy ra, tôi đã thay đổi công việc kể từ khi tôi viết điều đó và hiện tôi đang lập trình cho các thiết bị nhúng. Chúng tôi đang sử dụng C ++ và thật đáng chú ý những gì lập trình meta STL và mẫu có thể làm cho bạn khi bạn gặp khó khăn về phần cứng và thời gian thực cứng cũng như sự cần thiết về độ tin cậy. (Chúng tôi đang làm nhà máy điện.) Vâng, bạn phải biết liệu bạn nên sử dụng một std::vectorhoặc một std::mapmã nào đó - nhưng bạn không phải tự thực hiện nó, nhưng có thể dựa vào thử nghiệm tốt, hiệu suất cao, và triển khai thư viện đáng tin cậy cung cấp trừu tượng cao.
sbi

119

C được sử dụng rất nhiều trong lập trình phần cứng nhúng, nơi tài nguyên khan hiếm.

Nhân Linux được viết bằng C vì theo Linus Torvalds, C ++ là một ngôn ngữ kinh khủng .


14
Tôi nghĩ phần lớn nhân Windows cũng là C. Và rất nhiều hệ thống cũ.
Coder

14
Để hoàn thành, Linus đã thử dùng C ++ trong kernel. Đó là một vấn đề nhiều hơn một cộng. Dù sao, sự phát triển hạt nhân là một chủ đề thực sự cụ thể, điều đó không có nghĩa là C ++ nói chung là xấu.
deadalnix

75
Theo những người khác , lập luận của Linus thật kinh khủng.
sbi

36
Các đối số của Linus có thể có hoặc không hợp lệ, nhưng nhân Linux vẫn được viết bằng chữ C :-)
Joonas Pulakka

15
Linus là một git.
ubiyubix

94

Tất cả các ngôn ngữ hiện đại tôi đã thấy có thể tương tác với C:

  • C ++
  • Java
  • C #
  • Con trăn
  • Haskell
  • Mục tiêu C

Nhu cầu tương tác với C xuất phát từ:

  • C có ABI đơn giản
  • C tồn tại trong một thời gian dài

Điều đó có nghĩa là vì những ngôn ngữ đó có thể giao tiếp với C, họ có thể:

  • tận dụng các thư viện của nó
  • giao tiếp với nhau thông qua C (ví dụ, Clang được viết bằng C ++ nhưng cung cấp Python Bindings được nối trên giao diện C của nó).

Và tôi cá là tất cả bọn họ đều dựa vào C trong thời gian chạy của họ (trừ khi họ đi lắp ráp đầy đủ?

C là Lingua Franca của các ngôn ngữ lập trình và là một trong những ngôn ngữ đơn giản nhất (ABI-khôn ngoan) không bị ràng buộc với một kiến ​​trúc cụ thể (như lắp ráp), sẽ cần một sự thay đổi lớn để loại bỏ nó.


45

Theo tôi đây là một câu hỏi rất ngắn gọn giống như "Bạn bè của tôi và tôi nghe Reggae. Có ai thực sự vẫn nghe Rap không?".

Mỗi ngôn ngữ ngoài kia có công dụng của nó. Các ngôn ngữ khác nhau chắc chắn có hốc của họ. Nhưng hỏi về C! Tôi chắc chắn rằng ít người sử dụng C # hơn C hàng ngày (từ quan điểm hoàn toàn thiên vị khi làm việc trong một cửa hàng nơi không ai sử dụng C #).

Google nhanh chóng tìm kiếm sự phổ biến tương đối của các ngôn ngữ.
Tôi chắc chắn không ai trong số này là có thẩm quyền nhưng chúng ta có thể sử dụng nó để xem xu hướng:

http://www.tiobe.com/index.php/content/apersinfo/tpci/index.html
http://langpop.com/

Ngay cả khi nhìn vào tỷ lệ SO của câu hỏi trên thẻ:
https://stackoverflow.com/tags

  • C #: 209845
  • 16 thẻ khác
  • C: 38790

Vì vậy, C là 18 chủ đề phổ biến nhất trên SO (và có rất nhiều ngôn ngữ khác ở đó).

Lưu ý: Chỉ số TIOBE ở trên đã được cập nhật liên tục trong hơn một thập kỷ (và có một số dữ liệu quay lại 3 thập kỷ) được cho là để đo các kỹ sư làm việc trong từng ngôn ngữ (mặc dù tôi không biết điều đó chính xác đến mức nào). Trong số 10 ngôn ngữ hàng đầu trừ Java / Visual Basic, nó phản ánh những gì mọi người trong cửa hàng của tôi biết (mặc dù tỷ lệ của chúng tôi sẽ hơi khác nhau vì chúng tôi có cỡ mẫu nhỏ hơn nhiều).


1
Câu trả lời này làm tôi bối rối ... bạn tiếp tục về C # và sau đó hiển thị các thẻ câu hỏi SO nhưng không có câu hỏi nào thực sự có liên quan đến C đang được sử dụng. Mức độ phổ biến (đặc biệt là trên langpop, nơi họ sử dụng các truy vấn của công cụ tìm kiếm để xác định mức độ phổ biến) không thực sự cho thấy việc sử dụng ngôn ngữ hiện đại, chỉ là các tìm kiếm hiện đại trên một ngôn ngữ. Bạn phải tính đến các tìm kiếm, rằng C được sử dụng thường xuyên trong các trường Đại học cho các lớp cấp thấp hơn để có thể tăng số lượng truy vấn và cả các bài đăng SO.
Jetti

3
@Jetti: Đó là lý do tại sao tôi nói rõ ràng: I am sure none of this is authoritative but we can use it to see trendsNhưng tôi không đồng ý với tuyên bố thứ hai của bạn; C không còn là ngôn ngữ chính được giảng dạy tại các viện nghiên cứu cao hơn (nếu đó là đợt sinh viên mới tốt nghiệp sẽ không vô dụng như vậy). Ngày nay mọi người có xu hướng học Java / C # sharp. Ngoài ra báo cáo Tiobe là về công việc không truy vấn.
Martin York

Nhìn lại, dường như có một sự lựa chọn từ kém về phía tôi. Tôi không có nghĩa là các lớp số thấp (lớp bắt đầu), ý tôi là các lớp hệ thống (kiến trúc máy tính) là nơi C được sử dụng.
Jetti

4
Số lượng thẻ SO không xác định mức độ phổ biến ngôn ngữ nói chung, nó chỉ đơn giản cho thấy mức độ phổ biến ngôn ngữ giữa những người dùng SO .
Ed S.

4
@Ed S. Rõ ràng. Nhưng câu hỏi không phải là về sự nổi tiếng. Đó là về sự tồn tại của C như một ngôn ngữ. Số lượng thẻ SO cho chúng ta thấy rằng nó chắc chắn không phải là một ngôn ngữ chết. Việc C nằm trong top 2 trên các trang khác không làm cho nó trở thành ngôn ngữ được sử dụng nhiều nhất / thứ hai. Nhưng sự tồn tại của nó trong top 10 là một dấu ấn quan trọng rằng nó không chết. Tất nhiên không ai trong số này là bằng chứng chỉ là những chỉ số mạnh mẽ cho thấy C vẫn đang được sử dụng tích cực.
Martin York

23

Bạn có thể cần sử dụng C khi bạn thiếu tài nguyên và không cần các khả năng hướng đối tượng.

Nhiều phần mềm được sử dụng ngày nay vẫn được viết bằng C, chưa kể trình điều khiển phần cứng.

Theo chỉ số Tiobe , C vẫn là ngôn ngữ được sử dụng nhiều nhất.


Như tcrosley đề xuất, bạn có thể muốn xem xét câu hỏi liên quan này .


Bạn cũng nên kiểm tra một số bài viết liên quan về sự khác biệt giữa C và C ++, như wiki này hoặc ví dụ này.


4
ôi !! đó là một điểm tuyệt vời Tôi chưa bao giờ nghĩ rằng "các khả năng OOP thực sự bổ sung thêm chi phí cho ngôn ngữ". Cảm ơn đã làm cho điểm hợp lệ này rõ ràng. Bây giờ, tôi có thể hiểu, nơi C đi trước người khác
Pankaj Upadhyay

7
@Pankaj C ++ nói chung không nhất thiết phải thêm nhiều thời gian chạy, rất nhiều sự phức tạp của ngôn ngữ là nguyên tắc "không trả tiền cho những gì bạn không sử dụng" - nếu bạn không sử dụng ngoại lệ thì ngoại lệ không làm chậm hoặc thêm kích thước vào mã của bạn Trình biên dịch lớn hơn và phức tạp hơn
Martin Beckett

2
re C trong trường nhúng, xem thêm câu hỏi và câu trả lời này: lập trình
viên.stackexchange.com / questions / 84514 / TÌM

6
Bạn không bao giờ thực sự cần khả năng OOP, nó chỉ đơn giản hoạt động tốt trong một số tình huống.
Ed S.

2
@Jose Faeti: Sếp của tôi sẽ đồng ý vì sếp của tôi là một người có kinh nghiệm, lý trí. Anh ta không mua vào tôn giáo lập trình.
Ed S.

20

Có vẻ như bạn đang cố gắng thuyết phục bản thân rằng C là vô dụng và do đó có thể bị bỏ qua. Hãy phá vỡ câu hỏi của bạn:

"Tôi đoán rằng ai đó sẽ chỉ học C để thử nghiệm nếu có sự phát triển được thực hiện trong C."

Không, có nhiều lý do để học C. Ngay cả khi bạn không biết rằng tôi vẫn sẽ tránh sử dụng các câu lệnh mền như thế, đặc biệt là kết hợp với logic vòng tròn. Rõ ràng người ta cần biết ngôn ngữ mà mã được viết để có thể kiểm tra / sửa lỗi chính xác nhưng điều đó giả định rằng ngôn ngữ vẫn được sử dụng như một ngôn ngữ nhất định và đúng với mọi ngôn ngữ chứ không chỉ C.

"Theo hiểu biết của tôi, tất cả sự phát triển liên quan đến COM và thiết kế phần cứng cũng được thực hiện trong C ++."

Điều đó là không chính xác.

"Do đó, học C không có ý nghĩa gì nếu bạn cần sử dụng C ++. Tôi cũng không tin vào ý nghĩa lịch sử, vậy tại sao lại lãng phí thời gian và tiền bạc vào việc học C?"

Đây là logic đáng nghi ngờ nhất trong tất cả. Trước hết, ý nghĩa lịch sử là điều bạn nên tin vào, bởi vì nếu bạn đã biết rằng C là tập con của C ++ và, nhờ đó, biết C có thể giúp bạn trở thành một lập trình viên C ++ tốt hơn. Tất nhiên, C cũng có ảnh hưởng đến hầu hết các ngôn ngữ xuất hiện sau đó vì vậy lợi ích không dừng lại ở đó. Ngoài ra, vì C rất quan trọng nên nó không thể được coi là chỉ có ý nghĩa lịch sử. Nó vẫn được sử dụng rộng rãi và do đó không thể xuống hạng ở vị trí thứ cấp như thế. Bạn có thể lập luận rằng đó không phải là ngôn ngữ mà mọi lập trình viên cần sử dụng và có kiến ​​thức thấu đáo và điều đó sẽ đúng nhưng xin đừng xây dựng lập luận của bạn khi nói rằng bạn không tin vào điều gì đó mà không kiểm tra giá trị thực sự của nó trước.


7
C là tập con của C ++ , đó có phải ý bạn không ?? . C không phải là tập con của C ++; nguyên vẹn họ là khá khác nhau. Đúng, C ++ là sự cải tiến của C, hoặc đôi khi được gọi là C với các lớp và OOP , nhưng để nói C là một tập hợp con, không biện minh
Pankaj Upadhyay

7
C ++ chủ yếu là một superset của một phiên bản C và C đã đi theo một hướng hơi khác kể từ đó. Một số khía cạnh của các ngôn ngữ đã đi theo hướng song song, nhưng những khía cạnh khác thì không (và C ++ có rất nhiều thứ khác bên cạnh).
Donal Fellows

Tôi đồng ý bỏ phiếu để làm rõ thực tế đó, không phải tất cả các chương trình C hợp lệ đều là chương trình C ++ hợp lệ, tức là C ++ không phải là siêu thay thế của C. Tuy nhiên, đó là một thay thế về cách C đưa ra quyết định cho nó. một superset, như Donal Fellows đã đề cập. Nó chỉ đơn giản là không có ý nghĩa để nói rằng nó là nữa, khi nó không còn đúng nữa.
Joshua Hedges

16

Ngoài các hệ thống nhúng, hầu hết các ngôn ngữ mới hơn đều có cách giao tiếp với C. Khi viết thư viện mà bạn muốn có thời gian sử dụng dễ dàng trong tất cả các ngôn ngữ đó, C là một lựa chọn rõ ràng. C ++, mặc dù nó cũng có thể giao tiếp với một số ngôn ngữ (chẳng hạn như Python (chỉ CPython)), C ++ không thể giao tiếp với số lượng ngôn ngữ lớn hơn do một số tính năng của nó (đặc biệt là xáo trộn tên, nhưng các mẫu không giúp vấn đề này). C ABI là một trong những giao diện dễ sử dụng nhất (Tôi biết bạn có thể viết C ++ và sử dụng "C" bên ngoài cho giao diện. Tôi không quan tâm).

Nó cũng có lợi ích là C và C ++ thực sự là ngôn ngữ tốt nhất để lập trình hệ thống và thời gian biên dịch C nhanh hơn nhiều . Thời gian biên dịch C ++ đáng chú ý là tồi tệ nhất trong mọi ngôn ngữ tôi đã sử dụng.

Bây giờ trong khi có những ngôn ngữ khác muốn trở thành ngôn ngữ hệ thống phổ biến ngoài kia ( đặc biệt tôi biết về D ), phần lớn phần mềm được viết bằng C / C ++. Các ngôn ngữ như D yêu cầu ai đó tạo một trình bao bọc xung quanh thư viện C thay vì chỉ sử dụng trực tiếp (như bạn làm từ C ++).


D có thể gọi mã C trực tiếp, giống như C ++. Tất cả bạn cần nếu nguyên mẫu hàm (một lần nữa, giống như C ++). Bạn chỉ cần viết extern(C)bằng D, trong khi ở C ++, bạn viếtextern "C"
Peter Alexander

@Peter Alexander Tôi biết về extern (C) trong D. Đó là những gì tôi đã đề cập khi tôi nói tập tin trình bao bọc. Bạn không thể trực tiếp bao gồm tiêu đề C (mà bạn có thể làm trong C ++, giả sử tiêu đề C sử dụng "C" bên ngoài và có các khối #ifdef __cplusplus, phần lớn làm như vậy). Sau đó, có những sự không tương thích khác giữa việc chỉ sử dụng extern (C) (đặc biệt là cách xử lý chuỗi. Theo hiểu biết của tôi, chúng không có bộ kết thúc null trong D. Vì vậy, bạn phải thay đổi mảng đặc biệt khi chuyển nó sang C).
jsternberg

11

hãy xem langpop.com , đặc biệt là các biểu đồ từ Freshmeat và Google Code. Nó cho thấy C vẫn còn con đường phía trước.

C vẫn phổ biến trên các hệ thống mà bạn cần đến gần kim loại (tức là hệ thống nhúng) và thực hiện các ứng dụng đói.


4
KHÔNG MỞ URL này! Trang web không còn tồn tại nữa và URL chuyển hướng đến một số trang spam gây phiền nhiễu.
Nikolay Suvandzhiev

11

Tôi sử dụng nó gần như mỗi ngày để phát triển cho iPad / iPhone. Nhiều thư viện được viết bằng C và không có tương đương Objective-C. Vì vậy, có, nó vẫn được sử dụng, và bởi một trong những thiết bị mới nhất trên thị trường.

Với C, bạn có thể lập trình rất nhiều hệ thống nhúng, nó nhỏ và tiện dụng và có thể sẽ tồn tại trong nhiều năm tới (hay bạn không lãng phí thời gian cũng như không có tiền để học nó)


2
"Objective-C vẫn còn trẻ" thực ra là từ giữa những năm 1980, gần bằng tuổi C ++. Mặc dù vậy, hầu hết những người sử dụng nó đã không bắt gặp nó cho đến năm 2007.

Đúng, điều tôi muốn nói về cơ bản là có nhiều thư viện C không có tương đương trong Objective-C cho iOS. Thật vậy, bản thân ngôn ngữ, không còn trẻ chút nào (được kiểm tra bằng Wiki). Cảm ơn đã chỉ ra rằng.
Valentin Radu

7

Nói chung cho hệ thống nhúng C vẫn được sử dụng rộng rãi.

Câu hỏi này đưa ra một số ví dụ khác.

Các chỉ số TIOBE , mà cố gắng để phân loại ngôn ngữ bằng cách phổ biến / sử dụng , luôn đặt C ở các vị trí đầu tiên.


Vị trí thứ 2 (sau Java).
Martin York

7
Điều thú vị là cả C ++ và Java dường như đều có xu hướng giảm dần về mức độ phổ biến trong 10 năm qua, trong khi C vẫn ít nhiều tĩnh.
Paul R

7

Tính di động.

Tạo một danh sách của mọi hệ thống mà bạn nghĩ sẽ chạy mã C và sau đó là một danh sách tương tự cho mọi ngôn ngữ khác mà bạn thích.

Nếu bạn đưa ra câu trả lời giống như tôi thì kết luận là có.


5

Vâng, tôi nghĩ rằng C là ngôn ngữ mạnh mẽ nhất vì những lý do sau đây!

1) AT đầu tiên, Đó là ngôn ngữ hệ thống (có nghĩa là nó có thể được sử dụng để thực hiện lập trình cấp thấp với thời gian tối thiểu hoặc không có thời gian chạy).

2) Tốc độ của ứng dụng kết quả. Mã nguồn C có thể được tối ưu hóa hơn nhiều so với các ngôn ngữ cấp cao hơn vì bộ ngôn ngữ tương đối nhỏ và rất hiệu quả. Nó gần giống như bạn có thể lập trình bằng ngôn ngữ lắp ráp, mà không cần lập trình bằng ngôn ngữ lắp ráp. và bạn thậm chí có thể sử dụng lắp ráp và C cùng nhau!

3) C có ứng dụng trong lập trình phần sụn (phần cứng). Đó là do khả năng sử dụng / làm việc với lắp ráp và giao tiếp trực tiếp với bộ điều khiển, bộ xử lý và các thiết bị khác.

4) C là một khối xây dựng cho nhiều ngôn ngữ hiện được biết đến khác. Tra cứu lịch sử của C và bạn sẽ thấy rằng nó đã xuất hiện được một thời gian (vì ngôn ngữ lập trình vẫn tiếp tục). Hãy xem Python ví dụ một ngôn ngữ lập trình cấp cao hướng đối tượng đầy đủ. Nó được viết bằng C (có lẽ C ++ cũng vậy). Điều đó cho bạn biết nếu bạn muốn biết những gì đang diễn ra dưới mui xe bằng các ngôn ngữ khác; hiểu C và cách nó hoạt động là điều cần thiết.

Một ngôn ngữ ứng dụng được sử dụng để lập trình cấp cao, ví dụ như viết trình xử lý văn bản hoặc trò chơi. Ví dụ về ngôn ngữ ứng dụng là Java, C #. Lý do là bởi vì chúng chứa bộ sưu tập rác, gõ tự động, xác thực thời gian chạy, v.v. - trong đó trọng tâm là năng suất.

Một ngôn ngữ hệ thống được sử dụng để lập trình cấp thấp. ví dụ: Bộ điều khiển vi mô, trình điều khiển và nhân hệ điều hành. Các ví dụ bao gồm lắp ráp, C. Chúng yêu cầu ít hoặc không có thời gian chạy để chạy mã trực tiếp trên phần cứng và trọng tâm là lập trình viên có quyền kiểm soát trực tiếp phần cứng.

Nhìn chung, nó đang suy giảm như một ngôn ngữ ứng dụng, nhưng vẫn mạnh mẽ như một ngôn ngữ hệ thống.


1

Ồ vâng, nó được sử dụng. Tôi làm việc trong lĩnh vực xử lý gói mạng. Tôi đã ở hai công ty khác nhau nơi chúng tôi xử lý các gói mạng. Vì vậy, chúng tôi đang hoạt động ở cấp độ Ethernet hoặc IP, không phải ở cấp độ trên TCP.

Thật thú vị, trong cả hai công ty C đã được chọn hơn C ++. Tại một trong các công ty, một trong hai sản phẩm được xây dựng dựa trên nhân Linux, trong khi sản phẩm kia được xây dựng trong không gian người dùng Linux. Sản phẩm kernel rõ ràng được sử dụng C làm kernel Linux được lập trình bằng C, nhưng họ cũng chọn sử dụng C cho sản phẩm không gian người dùng. Cả hai sản phẩm được phát triển bắt đầu từ khoảng năm 2000 (sản phẩm kernel một chút trước năm 2000 và sản phẩm không gian người dùng một chút sau năm 2000).

Trong công ty nơi tôi đã đến sau đó, sản phẩm được xây dựng trên C, không phải trên C ++. Nó thực sự là sự tiếp nối của một dự án từ giữa những năm 1990, mặc dù do nhu cầu cải thiện hiệu suất gần đây, người ta đã quyết định rằng về cơ bản mọi thứ sẽ được viết lại. Chúng tôi có một tùy chọn để chọn C ++ do viết lại này, nhưng không làm như vậy.

Trong lĩnh vực xử lý gói mạng, hiệu năng được tính rất nhiều. Vì vậy, tôi muốn triển khai bảng băm của riêng mình có hiệu suất cao hơn các bảng băm hiện có. Tôi, không phải là tác giả bảng băm, là người chọn chức năng băm nào sẽ được sử dụng. Có lẽ tôi muốn hiệu suất và đi cho MurMurHash3 . Có lẽ tôi muốn bảo mật và đi cho SipHash . Cấp phát bộ nhớ rõ ràng là tùy chỉnh. Trong thực tế, tất cả các cấu trúc dữ liệu quan trọng chúng tôi sử dụng đã được triển khai tùy chỉnh để có hiệu suất cao nhất có thể.

Mặc dù không có gì có thể ngăn cản việc sử dụng C ++, nhưng đó thường là một ý tưởng tồi. Một ngoại lệ được ném cho mỗi gói sẽ giảm tốc độ xử lý gói xuống mức không thể chấp nhận được! Vì vậy, chúng tôi không thể sử dụng ngoại lệ của C ++. Cách quá chậm. Chúng tôi đã sử dụng loại mã C hướng đối tượng bằng cách triển khai các cấu trúc dữ liệu dưới dạng các cấu trúc và sau đó thực hiện các chức năng hoạt động trên các cấu trúc đó. C ++ sẽ cho phép có các chức năng ảo, nhưng sau đó các cuộc gọi chức năng ảo sẽ giết hiệu năng nếu được sử dụng ở mọi nơi. Vì vậy, tốt hơn là nên rõ ràng và có một con trỏ hàm nếu cần các lệnh gọi ảo.

C ++ sẽ làm rất nhiều thứ sau lưng bạn: cấp phát bộ nhớ, v.v. Mặt khác, trong C thường không xảy ra. Bạn có thể viết một hàm phân bổ bộ nhớ, nhưng thông thường thì rõ ràng từ giao diện của chức năng phân bổ đang diễn ra.

Ví dụ về loại tối ưu hóa vi mô mà bạn có thể thực hiện khi lập trình trong C, hãy xem macro container_of trong nhân Linux. Chắc chắn, bạn có thể sử dụng container_of trong mã C ++, nhưng ai làm điều đó? Ý tôi là, nó hoàn toàn có thể chấp nhận được trong hầu hết các chương trình C, nhưng các lập trình viên C ++ điển hình sẽ ngay lập tức đề xuất một cái gì đó khác, chẳng hạn như một danh sách được liên kết phân bổ các nút liên kết thành các khối riêng biệt. Chúng tôi không muốn điều đó bởi vì mọi khối bộ nhớ được phân bổ đều không tốt cho hiệu năng.

Có lẽ điều duy nhất có lợi cho chúng ta trong C ++ là C ++ cho phép lập trình siêu mẫu, nghĩa là đôi khi bạn có thể tránh các cuộc gọi hàm ảo trong khi vẫn có tham số hàm và cho phép trình biên dịch nội tuyến các hàm. Nhưng siêu lập trình mẫu rất phức tạp và chúng tôi đã quản lý để đáp ứng tất cả các yêu cầu trong C, vì vậy lợi ích của tính năng này trong C ++ không quá quan trọng.

Trong một trong các công ty, chúng tôi thực sự có một ngôn ngữ được biên dịch tùy chỉnh trong đó một phần của các tính năng được triển khai. Đoán xem đó là ngôn ngữ đích của trình biên dịch? Hội,, tổ hợp? Không, chúng tôi phải hỗ trợ cả kiến ​​trúc 32 bit và 64 bit. C ++? Chắc chắn bạn vui vẻ. Rõ ràng, đó là C với goto được tính toán của GCC . Vì vậy, ngôn ngữ tùy chỉnh đã được biên dịch thành C (hoặc thực tế là biến thể gcc của C hỗ trợ goto tính toán) và trình biên dịch C được sản xuất lắp ráp.


0

Tôi vẫn sử dụng C hàng ngày và một trong những lý do chính là do sự xen kẽ với các ngôn ngữ khác và SDK được thiết kế để sử dụng bởi các plugin được xây dựng bởi tất cả các loại trình biên dịch bằng nhiều ngôn ngữ khác nhau.

Tôi không thể viết API C ++ sử dụng các lớp có hàm tạo và hàm hủy và vtables, nạp chồng hàm, ném ngoại lệ, v.v. có thể được sử dụng từ Lua, C #, Python, C, v.v. và cài đặt từ chính chúng ta.

Tôi không thể viết SDK C # có thể được gọi từ Python, ví dụ hoặc SDK Python có thể được gọi từ C #.

C là ngôn ngữ duy nhất ở đây cho phép tôi tạo một API có thể được gọi từ bất kỳ ngôn ngữ nào trong số này. Điều đó nói rằng tôi thường sử dụng C ++ để thực hiện các giao diện C này (mặc dù đôi khi tôi chỉ thực hiện chúng trong C).

Bên cạnh đó, đôi khi tôi thấy C là ngôn ngữ dễ nhất để làm việc với những thứ như cấu trúc dữ liệu cấp thấp và bộ cấp phát bộ nhớ. Tất cả các loại an toàn bổ sung mà bạn có được trong C ++ không giúp ích gì nếu bạn đang viết bộ cấp phát bộ nhớ được thiết kế để gộp các bit và byte được căn chỉnh. Và chống lại hệ thống loại phong phú và xử lý ngoại lệ của C ++, không dễ để cuộn các cấu trúc dữ liệu của riêng bạn - chỉ cần nhìn xem cần bao nhiêu nỗ lực để viết một cấu trúc dữ liệu tầm thường như std::vectorthể bạn muốn làm cho nó an toàn ngoại lệ và tránh gọi các bác sĩ và bác sĩ về các yếu tố bạn không chèn vào bộ chứa (Tôi đang nói như một người đã triển khai toàn bộ thư viện chuẩn C ++). Khi chỉ là một mảng có thể phát triển là rất khó để thực hiện tốt, thì hãy tưởng tượng công việc cần thiết để thực hiện một BVH chất lượng sản xuất.

Tôi thích C ++ hơn C khi tôi muốn sử dụng các cấu trúc dữ liệu hiện có hoặc triển khai các cấu trúc dữ liệu cấp cao hơn bằng cách sử dụng các cấu trúc dữ liệu hiện có, nhưng nếu tôi sẽ triển khai cấu trúc dữ liệu cấp thấp ở lõi của một công cụ không sử dụng cho Cấu trúc dữ liệu hiện có, C chắc chắn làm cho việc thực hiện dễ dàng hơn rất nhiều với hệ thống loại đơn giản uber của nó cho phép bạn chỉ memcpynhững thứ ở đây và memmovenhững thứ ở đó, mallocmột khối liền kề và reallocở đó, mà không phải lo lắng về các nhà xây dựng, phá hủy và ngoại lệ bị ném.

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.