Ngôn ngữ lập trình C (những vấn đề của ngôn ngữ C)

 (hut.mearie.org)
15 điểm bởi dalinaum 2021-04-05 | 7 bình luận | Chia sẻ qua WhatsApp

  • Vấn đề bộ nhớ: không nhận được sự hỗ trợ từ các công cụ như GC, phân tích tĩnh, v.v.

  • Hành vi không xác định: thường được dùng chủ yếu trong môi trường mức thấp và có nhiều yêu cầu tối ưu hóa, vì vậy hành vi không xác định đã tăng lên để phục vụ tối ưu hóa. Không thể đồng thời đạt được cả hiệu năng mức thấp lẫn tính khả chuyển.

  • Không phù hợp với lập trình quy mô lớn: thiếu mô-đun, thiếu trình quản lý gói. Ngay cả những thứ được dùng rộng rãi như #pragma once cũng không có tiêu chuẩn.

Bài viết liên quan

7 bình luận

 
ffdd270 2021-04-05

Cảm ơn bạn đã chia sẻ một bài viết hay. Tuy nhiên, có một điểm nhỏ khiến tôi hơi thắc mắc nên để lại bình luận.

  • Có lẽ vào thời điểm bạn viết bài lần đầu năm 2011 thì chưa có, nhưng giờ đã xuất hiện một vài trình quản lý gói cho C. Có Conan, và cũng có vcpkg của MS. So với npm thì vẫn còn thiếu một vài điểm (vcpkg vẫn còn gắn nhãn beta cho phần quản lý phiên bản, còn conan thì có ít tài liệu hơn vcpkg), nhưng vẫn tốt hơn rất nhiều so với thời chưa có.
 
lifthrasiir 2021-04-09

Tôi là người viết bài đây (haha...). Hiện trang web vẫn đang ở giai đoạn phát hành mềm nên tôi đang thử nghiệm viết bài, vì vậy mong bạn thông cảm rằng nội dung có thể sẽ tiếp tục được chỉnh sửa. Tôi cũng tự theo dõi, nhưng cũng nhận góp ý qua email nên bạn có thể tham khảo nhé.

Đúng như bạn nói, hiện tại vcpkg có vẻ là trình quản lý gói hứa hẹn nhất, còn Conan thực ra cũng là một dự án đã tồn tại từ khá lâu rồi (không cách thời điểm bài gốc được viết bao xa). Tuy nhiên, đặc điểm lớn nhất của các dự án này là bản thân chúng không có hệ thống build riêng mà là các meta build system. (Nghĩ đến việc CMake, mục tiêu hỗ trợ chính của chúng, bản thân cũng là một meta build system thì có khi còn là meta-meta build system nữa...) Vì vậy, chúng khó có thể giải quyết triệt để các vấn đề phát sinh từ chính hệ thống build. Có thể thấy vcpkg có dấu vết được cân nhắc nhiều hơn; chẳng hạn nếu trong cùng một dự án cần các phiên bản khác nhau của cùng một dependency (thông qua các đường dẫn phụ thuộc khác nhau), thì có thể tách enlistment ra. Nhưng đây rốt cuộc cũng chỉ là cách lách giới hạn của chính hệ thống build mà thôi. Ví dụ, với Rust và Cargo thì trong trường hợp này có thể build cả hai phiên bản và tham chiếu chúng trong một crate mà không gặp trở ngại gì.

Ngoài ra, hiện tại có vẻ vcpkg trong Visual Studio còn chưa có nổi mức tích hợp công cụ như NuGet (chỉ có tích hợp MSBuild mà thôi...), và việc tích hợp với các trình quản lý gói của bản phân phối Linux/BSD dường như cũng chưa được bao nhiêu. Vấn đề này cũng là thách thức lớn nhất mà các trình quản lý gói theo ngôn ngữ đang đối mặt hiện nay; những ngôn ngữ mới như Rust thì đang giải quyết bằng cách đánh từng phần, nhưng nếu là trình quản lý gói cho C/C++ thì lẽ ra phải hướng tới việc tích hợp với các hệ thống sẵn có bằng mọi giá, vậy mà chuyện đó vẫn tiến triển rất chậm. Chỉ sau khi phần này được giải quyết thì khi ấy mới có thể nói rằng các hệ thống kiểu vcpkg đã trở thành công cụ có thể được dùng phổ biến trong phát triển C/C++. Việc chưa đạt được điều đó chính là lý do chủ yếu khiến tôi đánh giá thấp hệ thống gói trong bài viết. (Sự tràn lan của các single-file library mà tôi nêu trong bài cũng là một bằng chứng gián tiếp cho thấy các hệ thống kiểu vcpkg vẫn chưa đủ sức hấp dẫn.)
 
ffdd270 2021-04-12

Cảm ơn bạn vì câu trả lời chi tiết. Nghĩ lại thì gốc rễ của nó là build = hm.. nên khác với npm hay các package manager khác, có lẽ tồn tại một bức tường khó mà theo kịp được. Dạo này có vẻ vcpkg đang khá đau đầu về vấn đề phiên bản, nhưng xem ra sẽ không dễ để vượt qua.

Cũng có lúc tôi nghĩ liệu hệ thống module của C++20 có thể là lời giải cho vấn đề này không... nhưng như vậy thì phạm vi lại vượt ra khỏi ngôn ngữ C rồi (...). Có lẽ với C thì chỉ còn lại một con đường đầy chông gai. Dù bây giờ có ban hành C20 đi nữa thì tỷ lệ chuyển sang phiên bản mới cũng sẽ không cao như C++...
 
functor 2021-04-06

Cảm ơn ý kiến rất hay.

Đây là suy nghĩ cá nhân của tôi. Việc có một vài trình quản lý gói cho C là tín hiệu tích cực, nhưng vấn đề có lẽ là các trình quản lý gói này không được dùng nhiều. Nói chính xác hơn, vì di sản legacy của C đã quá đồ sộ, nên tôi cảm thấy có lẽ chúng ta đã đi quá xa để có thể giải quyết những vấn đề được nhắc đến ở trên. Vì vậy, chẳng phải cũng vì thế mà ngày càng có nhiều nỗ lực chuyển sang các ngôn ngữ mới như Rust hay sao.
 
ffdd270 2021-04-06

Nghe mọi người nói rồi nghĩ lại thì có vẻ trọng tâm của các trình quản lý gói ở trên không phải là kéo dài sự sống cho ngôn ngữ C, mà là kéo dài sự sống cho những lập trình viên buộc phải dùng C.

Giờ đến lúc phải chuyển sang ngôi nhà mới (C++, Rust...) rồi, khi cần đến những món đồ đạc như OpenGL hay Lua từng có ở ngôi nhà cũ, nếu không có trình quản lý gói thì phải tự tay chuyển từng thứ một (liên kết, chạy make, rồi vì phiên bản DLL hay lib không khớp mà rụng tóc... nhìn lỗi LNK rồi chỉ muốn nhảy lầu...) nhưng giờ có trình quản lý gói nên đã có thể chuyển đi gọn gàng như dùng dịch vụ chuyển nhà trọn gói. Vì những thứ đã làm ra từ trước quá nhiều nên chắc ở ngôi nhà mới đôi lúc vẫn phải dùng đến chúng...

Giờ nhìn vào việc lợi thế lớn hơn không còn là ưu điểm của bản thân ngôn ngữ, mà là giá trị của cả đống kinh nghiệm và tích lũy đã chồng chất từ trước đến nay, mới thật sự cảm nhận được đây là một ngôn ngữ đang dần chết đi (...)
 
galadbran 2021-04-08

Xét về nhiều mặt, có vẻ như Rust là ngôn ngữ mang hình ảnh “next C/C++” rõ rệt nhất. (Trong số một vài ngôn ngữ được xem là “next”, nó cũng có hình ảnh là tương đối phức tạp nhất... haha)
 
dalinaum 2021-04-10

Có vẻ như không chỉ hình ảnh, mà Rust ngoài thực tế cũng thực sự khó.