Các tính năng thử nghiệm của C ++ hiện đại có đáng tin cậy cho các dự án dài hạn không?


87

Tôi có một dự án hiện đang sử dụng C ++ 11/14, nhưng nó yêu cầu một cái gì đó như std::filesystem, chỉ có sẵn trong C ++ 17 và do đó tôi hiện không có cơ hội sử dụng nó. Tuy nhiên, tôi thấy rằng nó có sẵn trong trình biên dịch hiện tại của tôi dưới dạng std::experimental::filesystem. Bạn có nên sử dụng các tính năng thử nghiệm không, giả sử rằng trong tương lai tôi có thể thêm một số thứ như:

#ifdef CXX17 //if this is C++17
std::filesystem::something ...;
#else
std::experimental::filesystem::something ...;
#endif

Mối quan tâm của tôi là:

1. Có đảm bảo rằng tất cả các trình biên dịch tuân thủ đều có các tính năng thử nghiệm giống nhau không?

2. Các tính năng thử nghiệm có dễ bị thay đổi lớn khiến chúng không đáng tin cậy không?

Có lẽ còn nhiều điều cần băn khoăn. Tại sao tôi nên hoặc không nên sử dụng chúng? Tôi đang phân vân với một dự án mới và không biết phải quyết định điều gì.


25
từ thử nghiệm không trả lời câu hỏi của bạn?
101.010

6
Chủ yếu là vấn đề về sở thích, nhưng tôi sẽ tránh làm lộn xộn mã với #idef CXX17. IMHO, cách di động là đặt tất cả mã liên quan đến hệ thống tệp trong một đơn vị biên dịch duy nhất (có thể là một lớp), sử dụng nó trong suốt các phần còn lại của mã, mã hóa nó bằng tiêu chuẩn C ++ 11/14 hiện tại. Ghi lại lý do tại sao bạn viết nó như vậy, và cuối cùng chuyển nó sang C ++ 17 sau trong giai đoạn bảo trì, nếu nó có ý nghĩa. (bình luận về câu hỏi ban đầu)
Serge Ballesta

4
Nó chỉ là "thử nghiệm" như một ứng cử viên để vào tiêu chuẩn. Nó không phải là sự phản ánh chất lượng của mã.
Galik

5
Có khá nhiều thay đổi giữa phiên bản C ++ 17 "thử nghiệm" và cuối cùng, hãy xem tài liệu P0492R1
Bo Persson

7
Trong trường hợp của filesystembạn, rủi ro khi sử dụng nó ít hơn nhiều so với những thứ khác, vì bạn đã biết rằng nó được chuẩn hóa trong C ++ 17 và thông số kỹ thuật chính xác của C ++ 17 được công bố rộng rãi. Vì vậy, tất cả những gì bạn phải làm là đảm bảo rằng bạn chỉ sử dụng các experimental::filesystemtính năng có trong đặc tả C ++ 17. Và tất nhiên bạn phải biết rằng tất cả các nền tảng được nhắm mục tiêu của bạn đều hỗ trợ một trong hai experimental::filesystemhoặc C ++ 17 std::filesystem.
Howard Hinnant

Câu trả lời:


79
  1. Có đảm bảo rằng tất cả các trình biên dịch tuân thủ đều có các tính năng thử nghiệm giống nhau không?

Không, các tính năng thử nghiệm là tùy chọn.

  1. Các tính năng thử nghiệm có dễ bị thay đổi lớn khiến chúng không đáng tin cậy không?

Có, ủy ban C ++ thậm chí có thể quyết định từ bỏ một tính năng hoặc trong quá trình chuẩn hóa, một lỗi có thể xuất hiện buộc một tính năng phải thay đổi.

Nói chung, không nên phụ thuộc vào các tính năng thử nghiệm. Tính năng thử nghiệm là chính xác những gì từ đó nói (tức là thử nghiệm).


2
Đề cập đến điểm thứ hai, xin lưu ý rằng tôi đang nói về các tính năng đã được chấp nhận, nhưng thể khác.
The Quantum Physicist

14
@TheQuantumPhysicist: "đã được chấp nhận" là một khái niệm phức tạp. Mọi thứ có thể bị xóa bất kỳ lúc nào bằng cách chấp nhận thay đổi sau đó để xóa nó và điều này đã xảy ra với mọi tiêu chuẩn. Bạn có thể muốn đợi ít nhất là Dự thảo Tiêu chuẩn Quốc tế trước khi bộ tính năng đáng tin cậy một cách hợp lý.
Kerrek SB

1
@KerrekSB: Ý bạn không phải là Bản dự thảo cuối cùng Tiêu chuẩn quốc tế hay còn gọi là FDIS. ? Soạn thảo là một quá trình khá lâu dài.
MSalters

1
@MSalters: Không, DIS có thể đủ tốt nếu bạn đang vội. Và dù sao thì lần này chúng ta cũng có thể không có FDIS.
Kerrek SB

4
@KerrekSB: Tôi khá nhiều là Cơ quan Quốc gia cho Hà Lan xung quanh C ++ 03;). Chúng tôi đã có thư ký quốc gia về SC22, người biết về các thủ tục ISO và cách trả lời FDIS, nhưng không phải thế. Ngoài đại biểu WG14 Randy Marques của chúng tôi) không ai trong số đại biểu SC22 của chúng tôi biết bất cứ điều gì về C ++. Và Randy đã chỉ làm cho niềm vui của sự kiện là C ++ sẽ cần nhiều trang để xác định tất cả các UB của nó so với C cần thiết cho hành vi Defined - sẽ không muốn anh ta để trả lời rằng FDI;)
MSalters

50

Một người nào đó từ khán giả đã đặt câu hỏi trong buổi nói chuyện "Bảng điều khiển thư viện tiêu chuẩn C ++" tại CppCon 2016 ( YouTube ) về khả năng cái tên này experimentalkhiến người dùng sợ hãi không sử dụng bất cứ thứ gì trong không gian tên:

Các bạn có coi việc std::experimentalsản xuất [nội dung của không gian tên] đã sẵn sàng không và đó là một lập luận có thể được đưa ra, [rằng] nó đã sẵn sàng sản xuất hiệu quả trong 3 năm tới, và có thể bạn phải thay đổi mã của mình 3 năm sau, có thể không?

Michael Wong (chủ tịch SG5 và SG14 và biên tập viên của Concurrency TS) đã đưa ra câu hỏi trước:

Tôi nghĩ rằng có sự đồng thuận mạnh mẽ trong ủy ban rằng nó trên thực tế đã sẵn sàng sản xuất. Như tôi đã nói trước đây, trong hầu hết các trường hợp, 99% nó bị lọt khí vào. Chúng tôi muốn đảm bảo rằng nó không phải là trở ngại để bạn sử dụng nó. Bạn có thể hiểu lý do tại sao chúng tôi muốn đặt các tính năng lớn, các nhóm tính năng lớn, trong bối cảnh như vậy để nó không làm ảnh hưởng đến phần còn lại của toàn bộ hệ thống thư viện mà còn giúp bạn sử dụng dễ dàng hơn. Bây giờ bạn có thể bật GCC với một cờ cụ thể cho các khái niệm, bạn biết đấy, điều đó thực sự giúp bạn phân đoạn nó dễ dàng hơn.

Alisdair Meredith (cựu chủ tịch LWG) sau đó đã theo dõi:

Tôi sẽ đi ngược lại vị trí ở đây. Một trong những điều mà Herb [Sutter] đã nói với tư cách là người triệu tập WG21, nhóm tiêu chuẩn, khi chúng tôi bắt đầu con đường của TSes là, anh ấy không nghĩ rằng TSes sẽ thành công cho đến khi chúng tôi thất bại trong việc đưa ra điều gì đó về phía trước, bởi vì nó có nghĩa là chúng tôi không đủ thử nghiệm, chúng tôi không đủ tham vọng trong những gì chúng tôi đang sử dụng TSes. Chúng tôi thực sự muốn điều đóexperimentallà một gợi ý rằng, vâng, những thứ này có thể thay đổi, chúng tôi không ràng buộc với điều đó, và chúng tôi có thể làm sai. Điều này là để hạ thấp rào cản của chúng tôi đối với những thứ chúng tôi coi là tham vọng và đạt được nhiều nhất có thể [...] Bây giờ tiêu chuẩn dường như đang trong chu kỳ phát hành ba năm, chúng tôi nên tham vọng hơn nhiều trong việc đưa các tính năng thực sự thử nghiệm vào TS, và có lẽ tiến nhanh hơn vào tiêu chuẩn chính. Nhưng một lần nữa, đây sẽ là một chủ đề thú vị để chúng ta thảo luận trong một vài cuộc họp [ủy ban tiêu chuẩn C ++] sắp tới.

Stephan T. Lavavej (người duy trì triển khai STL của Microsoft) là người cuối cùng trả lời:

Điều quan trọng là phải phân biệt giữa tính thử nghiệm của giao diện và tính thử nghiệm của việc triển khai, bởi vì khi bạn nói "sẵn sàng sản xuất", điều đó có nghĩa là gì? Thông thường, "sản xuất sẵn sàng", bạn sẽ nghĩ về điều đó nói về việc thực hiện. Rất có thể việc triển khai [một thứ gì đó trong std::experimental] hoàn toàn [...] chống đạn. [...] Một cái gì đó giống như [...] <random>tiêu đề trong TR1, [nó] thực sự rất, rất hay trong TR1, và bạn có thể đã có một triển khai hoàn toàn chống đạn cho điều đó, nhưng hóa ra là giao diện bị xáo trộn về cơ bản [trước khi phát hành] C ++ 11 và [...] nếu chúng ta biết trước những gì chúng ta làm bây giờ, đưa vào dấu hiệu experimentalsẽ là một tín hiệu tốt hơn cho mọi người rằng, "Này, có thể bạn không muốn sử dụngstd::experimental::variate_generator bởi vì, ha-ha, nó sẽ biến mất trong C ++ 11 ".

Vì vậy, có vẻ như có một số mong muốn trong số các nhà phát triển thư viện tiêu chuẩn và các thành viên ủy ban rằng, ít nhất trong tương lai, nội dung của std::experimentalkhông gian tên phải thực sự là "thử nghiệm" về bản chất, và không nên coi đó là một thứ gì đó trong std::experimentalý muốn biến nó thành tiêu chuẩn C ++.

Và không, theo như tôi hiểu, tùy thuộc vào các nhà cung cấp thư viện tiêu chuẩn về việc họ có cung cấp các triển khai cho các tính năng khác nhau bên trong hay không std::experimental.


47
10 năm sau khi tôi lần đầu tiên đọc cái tên này, việc người bảo trì STL của Microsoft có tên là STL vẫn khiến tôi cười thầm.
Jörg W Mittag

19
@ JörgWMittag, bạn sẽ gặp người bảo trì trình biên dịch của họ, Michael Sam Victor Collins
MM

28

"Thử nghiệm" là một thuật ngữ hơi phóng đại. Các filesystemthư viện có nguồn gốc từ Boost và đã trải qua một vài lần lặp ở đó, trước khi trình ISO.

Tuy nhiên, các tiêu chuẩn ISO có chủ đích rất thận trọng. Gọi nó là thử nghiệm có nghĩa là ISO rõ ràng không hứa hẹn rằng việc đặt tên sẽ ổn định; rất rõ ràng rằng bạn sẽ cần giải quyết lại mã của mình một lúc nào đó trong tương lai. Nhưng biết ISO, có khả năng sẽ có hướng dẫn cách thực hiện.

Đối với khả năng tương thích giữa các trình biên dịch, hãy mong đợi nó hợp lý. Nhưng sẽ có những trường hợp ở góc (ví dụ như đường dẫn liên quan đến ổ đĩa Windows), và đó chính xác là lý do tại sao một tiêu chuẩn trong tương lai có thể phá vỡ mã hiện tại của bạn. Lý tưởng nhất, nó sẽ phá vỡ mã của bạn nếu và chỉ khi bạn phụ thuộc vào trường hợp góc đó, nhưng đó không phải là sự đảm bảo.


8

Có lẽ còn nhiều điều cần băn khoăn.

Một số điểm cần xem xét:

  • Làm thế nào đa nền là dự án của bạn? Nếu chỉ có một trình biên dịch tham gia, thì bạn có thể kiểm tra việc thực hiện và hồ sơ theo dõi của nó để quyết định. Hoặc hỏi họ!

  • Cơ sở mã của bạn lớn như thế nào? Tác động của những thay đổi sẽ lớn đến mức nào?

  • Các tính năng được cung cấp bởi API / thư viện / tính năng cơ bản như thế nào đối với dự án của bạn?

  • Các lựa chọn thay thế là gì?

    • Sử dụng tính năng thử nghiệm, sau đó điều chỉnh mã để sửa đổi khi / nếu nó được chuẩn hóa. Có thể dễ dàng như xóa experimental::hoặc khó như buộc các giải pháp thay thế.
    • Thêm một lớp trừu tượng (bình luận của Serge Ballesta). Nếu tính năng thử nghiệm thay đổi, việc ghi lại của bạn sẽ bị cô lập. Đối với một tính năng tiêu chuẩn, nó có thể quá mức cần thiết (std :: filesystem đã là một lớp trừu tượng ...).
    • Sử dụng API / thư viện khác. Câu hỏi tương tự: sự trưởng thành? cường tráng? sự ổn định? tính di động? dễ sử dụng? đặc trưng?
  • Trong trường hợp std :: filesystem (hoặc mạng TS), có boost :: filesystem (tương ứng với boost :: asio) như một giải pháp thay thế hoặc dự phòng, trong trường hợp experimentalmột lỗi hoặc không xuất hiện.
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.