2 điểm bởi GN⁺ 2025-01-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Những điểm cần cải thiện hiển nhiên của C

    • Tiêu chuẩn C23: Ngôn ngữ C được cải tiến định kỳ và hiện đã đạt đến C23. Tuy nhiên, vẫn còn những vấn đề chưa được giải quyết.
    • Nỗ lực của cộng đồng Dlang: Cộng đồng đã tích hợp trình biên dịch C (ImportC) vào trình biên dịch của ngôn ngữ lập trình D, qua đó tạo cơ hội để giải quyết những vấn đề này.
  • Đánh giá biểu thức hằng

    • Vấn đề: C có thể tính các biểu thức đơn giản tại thời điểm biên dịch, nhưng không thể thực thi hàm.
    • Giải pháp của ImportC: ImportC cho phép thực thi hàm tại thời điểm biên dịch để vượt qua hạn chế này.
  • Kiểm thử đơn vị tại thời điểm biên dịch

    • Vấn đề trong C: Kiểm thử đơn vị trong mã C cần một mục tiêu build riêng, gây phiền toái.
    • Ưu điểm của ImportC: ImportC cho phép dễ dàng chạy kiểm thử đơn vị thông qua việc đánh giá hàm tại thời điểm biên dịch.
  • Tham chiếu tiến cho khai báo

    • Hạn chế của C: C nhạy cảm với thứ tự khai báo nên không cho phép tham chiếu tiến.
    • Ưu điểm của ImportC: ImportC không bị ràng buộc bởi thứ tự khai báo và cho phép các khai báo toàn cục theo thứ tự tùy ý.
  • Nhập khai báo

    • Vấn đề của cách làm hiện tại: Có sự bất tiện khi phải viết tệp .h cho từng mô-đun bên ngoài.
    • Giải pháp của ImportC: ImportC có thể nhập khai báo mà không cần tệp .h, nên hiệu quả hơn.
  • Tài liệu tham khảo

    • Tài liệu ImportC: Cung cấp thông tin chi tiết về ImportC.
    • Tài liệu ngôn ngữ D: Cung cấp thêm thông tin về ngôn ngữ D.

1 bình luận

 
GN⁺ 2025-01-13
Ý kiến trên Hacker News
  • Các tệp header của ngôn ngữ C rất tốt ở chỗ có thể phân biệt rõ phần công khai và không công khai, giao diện và phần hiện thực. Có thể dễ dàng hiểu cách dùng thư viện thông qua tệp .h

    • Tài liệu thường tập trung trong tệp .h nên trông khác với tệp .c
    • Cũng có thể đưa tài liệu vào tệp .c, nhưng như vậy sẽ khiến giao diện khó đọc hơn
  • Có ý kiến cho rằng trong C nên có khả năng thực thi hàm tại thời điểm biên dịch, nhưng các hàm có thời gian chạy dài có thể gây vấn đề

    • Ví dụ là hàm busybeaver
  • Có người muốn biết cách giải quyết các vấn đề như đánh giá biểu thức hằng, unit test tại thời điểm biên dịch, tham chiếu xuôi của khai báo, và import khai báo

    • Đánh giá biểu thức hằng: nếu xử lý trong một đơn vị biên dịch thì khá đơn giản, nhưng sẽ cần lặp lại mã
    • Unit test tại thời điểm biên dịch: có thể biểu diễn bằng macro, nhưng nếu bổ sung điểm đầu tiên thì sẽ dễ hơn
    • Tham chiếu xuôi của khai báo: sẽ khiến trình biên dịch cần hai lượt duyệt, có thể ảnh hưởng hiệu năng
    • Import khai báo: có thể làm hỏng cách hiện thực template trong C
  • Việc viết unit test cho mã C là khả thi với một hệ thống build tốt và một ít boilerplate

    • Ví dụ là mã kiểm thử của thư viện npy
  • Khi việc đánh giá biểu thức hằng trở nên phức tạp, tốc độ của trình biên dịch có thể giảm và có thể sẽ cần một VM

    • Có ý kiến cho rằng thay vì định nghĩa như trong C++20, sẽ tốt hơn nếu đi theo hướng import module dưới dạng symbol
  • Unit test tại thời điểm biên dịch lấy đi quyền kiểm soát của lập trình viên và đòi hỏi các thủ tục không cần thiết để hoàn thành công việc

    • Kiểm thử thất bại khi build thì tốt cho bản build cuối cùng, nhưng không phù hợp với các bản build trung gian
  • Có thảo luận về việc liệu định nghĩa hàm theo kiểu "từ trên xuống" có tốt hơn hay không

    • Ngay cả trong các ngôn ngữ như Python, định nghĩa từ trên xuống cũng là cách phổ biến
    • Đặt ra câu hỏi liệu định nghĩa từ trên xuống có phù hợp hơn với một số loại mã cụ thể hay không
  • Những tính năng được mong muốn bổ sung vào C

    • Hỗ trợ kiểu slice mã hóa con trỏ và độ dài
    • API có khả năng tái nhập và an toàn luồng
    • Chuẩn hóa tính năng như defer của Go và Zig
    • Hỗ trợ portable cho Unicode và UTF-8
  • Cách hiện thực đơn giản của C là một ưu điểm, và việc mở rộng phạm vi quá lớn không phải là ý tưởng hay

    • Có thể có đặc tả phiên bản "nhỏ" và phiên bản "lớn" như Scheme
  • Lý do vì sao định nghĩa hàm từ trên xuống có thể tốt hơn

    • Tương tự với cách viết mã bên trong một hàm
    • Vị trí của các hàm trong module trở nên rõ ràng
    • Có thể nhận diện rõ các phụ thuộc vòng
    • Phụ thuộc vòng làm codebase phức tạp hơn và khiến module khó hiểu hơn
    • OCaml không cho phép phụ thuộc vòng giữa các hàm