Lập trình C năm 2011 [đã đóng]


19

Nhiều mặt trăng trước đây tôi đã cắt mã C để kiếm sống, chủ yếu là trong khi duy trì máy chủ POP3 hỗ trợ nhiều hệ điều hành (Linux, * BSD, HPUX, VMS ...).

Tôi đang dự định đánh bóng các kỹ năng C của mình và tìm hiểu một chút về việc thực hiện ngôn ngữ bằng cách mã hóa một FORTH đơn giản trong C.

Nhưng tôi tự hỏi làm thế nào (hoặc liệu?) Có những thứ thay đổi trong thế giới C kể từ năm 2000. Khi tôi nghĩ C, tôi nghĩ ...

  1. comp.lang.c
  2. ANSI C bất cứ nơi nào có thể (nhưng C89 như C99 không được hỗ trợ rộng rãi)
  3. gcc -Wall -ansi -pedantic thay cho các công cụ phân tích tĩnh
  4. Emacs
  5. Ctags
  6. Autoconf + make (và xem điểm 2 về độ tốt của VMS, HP-UX, v.v.)

Bất cứ ai đã viết bằng C trong mười một năm qua có thể cho tôi biết những gì (nếu có gì ;-)) đã thay đổi trong những năm qua không?

(Trong một tin khác, tào lao thần thánh, tôi đã làm điều này trong hơn một thập kỷ).



3
Chà, có vi thay vì emacs, nhưng tôi sẽ không đến đó. Tôi sẽ ngạc nhiên nếu bất cứ ai vẫn đăng bài lên comp.lang.c, và ngay cả cuộc thi C khó hiểu cũng bị đình trệ ( www0.us.ioccc.org/main.html ). Thời gian buồn - cuộc thi mới tiếp theo dành cho các chuỗi chữ cái bị xáo trộn đánh vần một số cụm từ tin nhắn văn bản, lol.
Jay Elston

Câu trả lời:


10

Thật khó cho tôi khi nghĩ lại thời gian như "Wow, lập trình C như 10 năm trước là gì?", Nhưng tôi có thể nói về một số điều mà tôi biết tôi đang làm khác đi.

  • Mặc dù bạn thường vẫn có thể triệu tập ai đó như Peter Seebach trên comp.lang.c để được trợ giúp về một lỗi đặc biệt ngớ ngẩn mà bạn nghi ngờ có thể liên quan đến ngôn ngữ, hầu hết nếu không phải tất cả các câu hỏi lập trình C đều nhận được câu trả lời đặc biệt trên Stack Overflow.

  • Phân tích tĩnh vẫn là loại đau đớn. Nẹp (ít nhất là theo như tôi biết) không giải quyết tốt với C99, đồ thị vùng phủ sóng vẫn còn một chút khó khăn để hình dung. Các cảnh báo của GCC đã "cải thiện" khá nhiều (trong ngoặc kép vì điều đó phụ thuộc vào người bạn hỏi).

  • Valgrind là vị thánh của tất cả các trình kiểm tra lỗi bộ nhớ và thường chỉ cho bạn các vấn đề trong mã của bạn mà không công cụ phân tích tĩnh nào có thể / có thể tìm thấy. Nó không hoàn hảo 100%, nhưng tôi không nghĩ nó có thể. Tôi rất hiếm khi phải chạm vào GDB những ngày này, mà (không có gì cá nhân) là tốt với tôi. Công cụ massif Valgrind là một profiler heap thực sự tốt là tốt.

  • Luôn có các tiện ích mở rộng mới trong GCC, một số trong số chúng tinh tế , vì vậy, rất tuyệt vời là một ý tưởng tốt nếu tính di động là mối quan tâm lớn. Đối với người lập trình mới / rỉ sét, đôi khi rất dễ nhầm lẫn các tiện ích mở rộng với các tính năng ngôn ngữ 'ẩn'.

  • CCAN đã xuất hiện (nghĩ CPAN, nhưng đối với C) và đang bắt đầu cất cánh. Có rất nhiều viên ngọc hữu ích ở đó, bao gồm cả việc điều chỉnh TAP, một công cụ kiểm tra tuyệt vời. Các chuỗi trong C vẫn còn hút, nhưng số lượng và chất lượng của các thư viện để giúp đối phó với chúng chắc chắn đã tăng lên trong mười năm qua.

  • SCons và CMake đang ngày càng phổ biến cho cấu hình xây dựng. Autoconf / Automake / Libtool vẫn được sử dụng rộng rãi, nhưng nhiều người cảm thấy hơi bị giới hạn bởi M4. Tuy nhiên, nếu đó là hệ thống bạn muốn sử dụng, kho lưu trữ macro Autoconf vẫn còn sống và tốt.

  • Rõ ràng có nhiều biên tập viên có sẵn ngày hôm nay. Tôi vẫn chưa tìm thấy một "IDE" nào cản trở tôi khi làm việc với C, nhưng đó có lẽ là vì tôi là một nhà truyền giáo uống rượu Sanka già nua, đơn giản.

Tuy nhiên, nhìn chung, tôi sẽ không nói cuộc sống (theo như C đi) thậm chí gần với sự khác biệt sâu sắc so với 10 năm trước. Nhưng, theo nhiều cách, nó thực sự dễ dàng hơn một chút. Thật khó để quy kết rằng các công cụ qua kinh nghiệm mặc dù.


15

glib có thể là "thư viện tiêu chuẩn mới". Nó cung cấp phần lớn những gì nhiều người cảm thấy bị bỏ qua ngoài tiêu chuẩn - kết nối và kết nối độc lập với nền tảng, cấu trúc dữ liệu của bộ chứa, v.v ... Tất nhiên, nó không thể áp dụng ở mọi nơi, nhưng nếu bạn có thể sử dụng nó, nó sẽ tiết kiệm rất nhiều thời gian.


Tôi nghĩ rằng bạn đang nhầm lẫn với Thư viện GNU C (GLibC)
Lekensteyn

7
Không, tôi không bối rối.
zvrba

1
Đây là một câu trả lời hoàn toàn hợp lệ, tôi không chắc tại sao nó lại được bình chọn. Glib được sinh ra từ nhiều người thất vọng với Ulrich Drepper và glibc 'được bảo vệ' như thế nào.
Tim Post

1
Mặc dù vậy, Glib hoàn toàn tách rời khỏi Gnome. Tôi không tranh luận về sự liên kết này, chỉ là về mặt thực tế, bạn hoàn toàn có thể bỏ qua Gnome và thậm chí GTK +. Có (rất nhiều?) Dòng lệnh và các chương trình không tương tác được viết trong đó.
gièm pha

3
Tôi thích gọi glib là "STL of C"
Cercerilla

4
  1. StackOverflow ;)
  2. Tôi sử dụng C chủ yếu để viết phần sụn cho vi điều khiển của Microchip và vì trình biên dịch của chúng là GCC dựa trên nên tôi sử dụng C99 (nhưng tôi không sử dụng các tính năng bổ sung, chủ yếu là để hạn chế phạm vi của các biến vòng lặp và mảng động trên ngăn xếp). Khi tôi viết các phần mở rộng Python, tôi sẽ sử dụng C89 trong trường hợp ai đó cần biên dịch nó với MSVC. Tôi không biết những gì người khác sử dụng.
  3. Splint (hoạt động trên C89, không phải C99) và máy phân tích tĩnh của Clang - mặc dù, vì cả hai đều nghẹt thở với mã phần mềm nặng vĩ mô, tôi không có nhiều kinh nghiệm với chúng. Trên thực tế, phần lớn các công cụ của LLVM khá thú vị đối với một người đam mê C.
  4. Được rồi, đây chỉ là mồi nhử chiến tranh: P
  5. Không bao giờ sử dụng Ctags, nhưng tôi là một phần của Doxygen.
  6. Chúa tôi ghét Autoconf. Tôi ghét nó quá nhiều. Tôi chưa bao giờ, đã từng chế tạo được một quả bóng bùn Autoconf từ đầu. Nếu một dự án đã có một dự án, tôi sẽ chỉ là kẻ khốn nạn bất cứ điều gì đã có. Nếu tôi đang viết một cái gì đó mới, tôi sẽ phát cuồng và tìm kiếm các lựa chọn thay thế, mặc dù tôi bị nguyền rủa nếu tôi tìm thấy một thứ mà tôi gắn bó. Lần trước khi tôi trải qua chu trình này, tôi đã giải quyết được SCons, mà tôi có thể sử dụng lại.

1
Tôi cũng sẽ đề nghị Cppcheck cho phân tích tĩnh.
Greg Hewgill

10
liên quan đến điểm số 6: "Tôi đã thấy một cuốn sách vào ngày khác có tên là 'Die Gnu Autotools', tôi đã suy nghĩ 'Heck Yeah!' cho đến khi tôi nhận ra tiêu đề là tiếng Đức ".
Cercerilla

2

2) và 3) đã thay đổi. C99 là chủ đạo, C90 đang ngày càng lỗi thời. gcc -Wall -std=c99 -pedantic.

Ngoài ra, hai thay đổi đáng chú ý nhất chưa được đề cập trong các câu trả lời khác là:

  • C11. ISO 9899: 2011.
  • MISRA-C: 2004.

1

Ngôn ngữ lập trình C đã đưa nó trở thành 2 hoặc 3 ngôn ngữ lập trình hàng đầu trên tạp chí của Tiến sĩ Dobb trong nghiên cứu / khảo sát gần đây nhất.

Đối với việc triển khai một ngôn ngữ, C được sử dụng để triển khai một ngôn ngữ mới đang được xây dựng tại Google, được gọi là Go (golang.org).

Tôi đã không theo dõi nhóm usenet của C trong những năm gần đây. Tôi thường xuyên ghé thăm kênh Freenode IRC của nó. Nó là hoạt động và thường xuyên của nhiều người.

Các chương trình mới đang được viết bằng C, nhưng chúng không được công khai như chúng sẽ có nếu năm nay sẽ diễn ra vào năm 1999.

Đây là một cái gì đó đến đỉnh của tâm trí. Có thể có nhiều hơn nữa, nhưng tôi hy vọng bạn vẫn giữ liên lạc với chiếc mũ lập trình viên của mình, mặc dù bạn có thể không thường xuyên sử dụng mô hình C của chiếc mũ :)


0

Tôi nghĩ rằng hỗ trợ C99 tốt hơn bạn nghi ngờ. Visual Studio không hỗ trợ nó, nhưng mọi trình biên dịch khác tôi có thể nghĩ đến đều hỗ trợ nó (với, có lẽ một vài thiếu sót ở đây và đó). Nếu bạn không cần khả năng tương thích với VS, thì tôi muốn nói với C99, vì nó dễ chịu hơn nhiều so với C89 IMHO.

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.