Tôi phải thừa nhận rằng tôi vẫn viết mã giả C89 (không hoàn toàn tuân thủ C99) chủ yếu vì Microsoft. Tôi dựa rất nhiều vào MSVC cho phía Windows và họ vẫn chưa hoàn toàn tuân thủ C99, thay vào đó, họ tập trung phần lớn vào C ++ 17 trở đi.
Trên hết, tôi đang làm việc trên SDK C mà rất nhiều nhà phát triển plugin sử dụng MSVC để phát triển plugin của họ và một số vẫn là MSVC 2010. Vì vậy, vẫn có các trình biên dịch phổ biến được sử dụng rộng rãi trên các nền tảng không quá kỳ lạ (trừ khi bạn xem xét Windows kỳ lạ) thậm chí chưa thực hiện đầy đủ C99. Khi bạn nhắm mục tiêu khả năng tương thích rộng với phạm vi trình biên dịch lớn nhất (đó là một trong những lý do chính khiến SDK được viết bằng C chứ không phải C ++), vẫn còn một số trong số chúng được sử dụng rộng rãi (ít nhất là MSVC). khi nói đến hỗ trợ C. Đã gần một vài thập kỷ kể từ C99 và chúng tôi vẫn không có VLAs, ví dụ, trong MSVC AFAIK (chưa kiểm tra MSVC 2017 nhưng đã đưa ra lập trường của Microsoft về C, tôi nghi ngờ rằng nó phù hợp hơn với C99) .
Và vì vậy, vẫn không may là các trình biên dịch mới thực sự khá tốt với các trình tối ưu hóa và trình gỡ lỗi tốt mà thậm chí còn không hoàn toàn tuân thủ C99. Tất nhiên, nếu không phải như vậy, tôi sẽ nhảy qua C11.
Bên cạnh khả năng tương thích nguồn với plugin và MSVC, còn có sự tương tác với các ngôn ngữ khác. Một số ngôn ngữ khác sử dụng SDK thông qua FFI và một số ngôn ngữ FFI đó chỉ hiểu C89. Họ có thể không hiểu boolhoặc _Boollà một ví dụ đơn giản khi nhập các hàm từ dylib và chỉ hiểu, nói , int.
Đúng, đối số có lợi là tính di động nhưng câu hỏi đặt ra là nếu thực sự có các hệ thống phi giả thuyết chỉ có thể sử dụng trình biên dịch C89 nhưng đang biên dịch các bản phân phối phần mềm mới. tức là nếu tôi đang bắt đầu một dự án C mới, tôi sẽ quyết định như thế nào nếu tuân thủ C89 có thể tăng số lượng người dùng tiềm năng?
Chỉ cần chú ý điều này nhưng loại tiếng vang Blrfl, việc tăng năng suất bằng cách sử dụng C99 và C11 không quá lớn trong trường hợp của tôi trong khi mất khả năng cho phép mọi người viết plugin của họ trong MSVC có thể là một chi phí rất lớn (đặc biệt là từ sản phẩm tôi làm việc trên có thị phần lớn nhất, cho đến nay, về phía Windows và người dùng trung bình thường mua và tải xuống nhiều plugin của bên thứ ba). Loại sản phẩm tôi làm việc gần như là một nửa giữa môi trường phát triển dành cho lập trình viên / người viết kịch bản và sản phẩm dành cho người dùng dành cho nghệ sĩ, vì rất nhiều người muốn phát triển những thứ mới trên đầu trang để cho phép các khả năng mới và đạt được hiệu ứng đặc biệt của những người tử tế chưa nhìn thấy. Vì vậy, trong trường hợp của tôi, đó thực sự là một quyết định khá đơn giản để ủng hộ C89 ít nhất là cho SDK.
Tôi cho rằng bạn phải nhìn vào các trình biên dịch xung quanh bạn và cố gắng tìm ra nhân khẩu học mục tiêu của bạn. Nếu bạn không phát triển kiến trúc plugin cho Windows hoặc thực hiện bất kỳ chương trình nhúng nào hoặc cố gắng xây dựng bộ công cụ phát triển phần mềm có thể được sử dụng bởi phạm vi trình biên dịch và ngôn ngữ rộng nhất ngoài đó, thì chắc chắn sẽ giúp mọi thứ dễ dàng hơn với C99 + xa. Cũng có thể xem xét mức tăng năng suất mà bạn có được từ mẫu C99 trở đi. Tôi không được hưởng lợi nhiều từ những thứ như VLAs vì tôi dựa vào những cách đơn giản để sử dụng ngăn xếp khi dữ liệu phù hợp và heap khác.
Nhưng có rất nhiều thứ bị tụt hậu so với các trình biên dịch phổ biến như MSVC sang FFI trong các ngôn ngữ khác, theo nghĩa là chúng có thể nhập và gọi các hàm C trực tiếp từ một dylib, nhưng cũng có thể bị chậm một chút so với lần Vì vậy, có rất nhiều điều kinh doanh thực tế để xem xét, tùy thuộc vào tên miền của bạn, thay vì chỉ đơn giản là ưu tiên cũ hơn và tiêu chuẩn hóa cho một số loại thẩm mỹ.