Apakah fitur eksperimental C ++ modern dapat diandalkan untuk proyek jangka panjang?

87

Saya memiliki proyek yang saat ini menggunakan C ++ 11/14, tetapi membutuhkan sesuatu seperti std::filesystem, yang hanya tersedia di C ++ 17, dan karenanya saya tidak memiliki kesempatan untuk menggunakannya saat ini. Saya melihat, bagaimanapun, bahwa itu tersedia di kompiler saya saat ini sebagai std::experimental::filesystem. Apakah ide yang baik untuk menggunakan fitur eksperimental, dengan asumsi bahwa saya dapat menambahkan sesuatu seperti ini di masa mendatang:

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

Kekhawatiran saya adalah:

1. Apakah dijamin bahwa semua kompiler yang sesuai memiliki fitur eksperimental yang sama?

2. Apakah fitur eksperimental rentan terhadap perubahan besar yang membuatnya tidak dapat diandalkan?

Mungkin ada lebih banyak hal yang perlu ditanyakan. Mengapa saya harus atau tidak boleh menggunakannya? Saya bingung dengan proyek baru dan tidak tahu harus memutuskan apa.

c++  c++11  portability  c++17  c++-standard-library 
— Fisikawan Kuantum
sumber
25
bukankah kata eksperimental menjawab pertanyaan Anda?
— 101010
6
Terutama masalah selera, tetapi saya akan menghindari untuk mengacaukan kode #idef CXX17. IMHO, cara portabel adalah dengan meletakkan semua kode terkait sistem file dalam satu unit kompilasi tunggal (mungkin kelas), gunakan di seluruh bagian kode yang tersisa, kodekan dengan standar C ++ 11/14 saat ini. Dokumentasikan bagaimana dan mengapa Anda menulisnya seperti itu, dan akhirnya port ke C ++ 17 nanti selama fase pemeliharaan, jika masuk akal. (Mengomentari pertanyaan awal)
— Serge Ballesta
4
Itu hanya "eksperimental" sebagai calon untuk memasuki standar. Ini bukan cerminan dari kualitas kode.
— Galik
5
Ada cukup banyak perubahan antara versi "eksperimental" dan final C ++ 17, lihat dokumen P0492R1
— Bo Persson
7
Dalam kasus filesystemAnda menanggung risiko yang jauh lebih kecil dalam menggunakannya daripada hal-hal lain, karena Anda sudah tahu bahwa itu distandarisasi dalam C ++ 17, dan spesifikasi C ++ 17 yang tepat tersedia untuk umum. Jadi yang harus Anda lakukan adalah memastikan bahwa Anda hanya menggunakan experimental::filesystemfitur yang ada dalam spesifikasi C ++ 17. Dan tentu saja Anda harus tahu bahwa semua platform yang Anda targetkan mendukung salah satu experimental::filesystematau C ++ 17 std::filesystem.
— Howard Hinnant

Jawaban:

79
  1. Apakah dijamin bahwa semua kompiler yang sesuai memiliki fitur eksperimental yang sama?

Tidak, fitur eksperimental bersifat opsional.

  1. Apakah fitur eksperimental rentan terhadap perubahan besar yang membuatnya tidak dapat diandalkan?

Ya, komite C ++ bahkan mungkin memutuskan untuk meninggalkan fitur atau dalam proses standarisasi cacat mungkin muncul yang akan memaksa fitur berubah.

Umumnya, bergantung pada fitur eksperimental bukanlah ide yang baik. Fitur eksperimental persis seperti yang dikatakan kata (yaitu, bereksperimen).

— 101010
sumber
2
Mengacu pada poin kedua, harap dicatat bahwa yang saya bicarakan adalah fitur yang sudah diterima, tetapi mungkin berbeda.
— Fisikawan Kuantum
14
@TheQuantumPhysicist: "sudah diterima" adalah konsep yang rumit. Apa pun dapat dihapus kapan saja dengan menerima perubahan untuk menghapusnya nanti, dan ini terjadi pada setiap standar. Anda mungkin ingin menunggu hingga setidaknya Draf Standar Internasional sebelum set fitur cukup andal.
— Kerrek SB
1
@KerrekSB: Bukan maksudnya Final Draft International Standard alias FDIS. ? Drafting adalah proses yang cukup permanen.
— MSalters
1
@ MSalters: Tidak, DIS mungkin cukup baik jika Anda sedang terburu-buru. Dan mungkin kali ini kami tidak memiliki FDIS.
— Kerrek SB
4
@KerrekSB: Saya cukup banyak adalah Badan Nasional untuk Belanda sekitar C ++ 03;). Kami memiliki seorang sekretaris nasional untuk SC22 yang tahu tentang prosedur ISO dan bagaimana menjawab FDIS, tapi tidak tahu apa. Selain delegasi WG14 kami Randy Marques) tidak ada delegasi SC22 kami yang tahu apa-apa tentang C ++. Dan Randy hanya mengolok-olok fakta bahwa C ++ akan membutuhkan lebih banyak halaman untuk mendefinisikan semua UB daripada C yang dibutuhkan untuk Defined Behavior - tidak ingin dia membalas FDIS tersebut;)
— MSalters
50

Seseorang dari audiens mengajukan pertanyaan selama sesi "C ++ Standard Library Panel" di CppCon 2016 ( YouTube ) tentang potensi nama tersebut experimentaluntuk menakut-nakuti pengguna agar tidak menggunakan apa pun di dalam namespace:

Apakah kalian menganggap produksi [isi std::experimentalnamespace] sudah siap dan apakah itu argumen yang bisa dibuat, [bahwa] produksi itu efektif siap untuk 3 tahun ke depan, dan mungkin Anda harus mengubah kode Anda 3 tahun kemudian, mungkin?

Michael Wong (ketua SG5 dan SG14 dan editor Concurrency TS) mengajukan pertanyaan terlebih dahulu:

Saya pikir ada konsensus yang kuat di dalam komite bahwa itu praktis siap produksi. Seperti yang saya katakan sebelumnya, dalam banyak kasus 99% darinya jatuh ke udara. Kami ingin memastikan bahwa itu bukan halangan bagi Anda untuk menggunakannya. Anda dapat memahami mengapa kami ingin menempatkan fitur-fitur besar, kelompok-kelompok fitur yang besar, dalam konteks seperti itu, sehingga tidak mengganggu sistem library keseluruhan, tetapi juga memudahkan Anda untuk menggunakannya. Sekarang Anda dapat mengaktifkan GCC dengan tanda khusus untuk Konsep, Anda tahu, itu sebenarnya memudahkan Anda untuk menyegmentasikannya.

Alisdair Meredith (mantan ketua POKJA) kemudian menindaklanjuti:

Saya akan mengambil posisi sebaliknya di sini. Salah satu hal yang dikatakan Herb [Sutter] sebagai penyelenggara WG21, kelompok standar, ketika kita memulai jalur TSes adalah, dia tidak berpikir bahwa TSes akan berhasil sampai kita gagal membawa sesuatu ke depan, karena itu berarti kami tidak cukup eksperimental, kami tidak cukup ambisius untuk tujuan penggunaan TS. Kami sangat menginginkan ituexperimentaluntuk menjadi petunjuk bahwa, ya, hal-hal ini dapat berubah, kami tidak mengikatnya, dan kami dapat melakukan kesalahan. Ini untuk menurunkan penghalang kami untuk hal-hal yang kami anggap sebagai ambisius dan mencapai yang kami bisa [...] Sekarang standar tampaknya berada pada siklus rilis tiga tahun, kami harus jauh lebih ambisius dalam menempatkan fitur yang benar-benar eksperimental ke TS, dan mungkin memajukan sesuatu dengan lebih cepat ke standar utama itu sendiri. Tapi sekali lagi, ini akan menjadi topik yang menyenangkan untuk kita bahas pada beberapa pertemuan [C ++ standard committee] berikutnya.

Stephan T. Lavavej (pengelola implementasi STL Microsoft) terakhir menanggapi:

Penting untuk menarik perbedaan antara eksperimentalitas antarmuka dan eksperimentalitas penerapan, karena ketika Anda mengatakan "produksi siap", apa artinya itu? Biasanya, "produksi siap", Anda akan memikirkan itu berbicara tentang implementasi. Sangat mungkin untuk implementasi [dari sesuatu std::experimental] menjadi benar-benar [...] anti peluru. [...] Sesuatu seperti [...] <random>tajuk di TR1, [itu] sangat, sangat bagus di TR1, dan Anda dapat memiliki penerapan yang benar-benar anti peluru, tetapi ternyata antarmuka bergejolak secara substansial [sebelum rilis] C ++ 11 dan [...] jika kami tahu dulu apa yang kami lakukan sekarang, memasukkannya experimentalakan menjadi sinyal yang lebih baik bagi orang-orang bahwa, "Hei, mungkin Anda tidak ingin menggunakanstd::experimental::variate_generator karena, ha-ha, itu akan hilang di C ++ 11 ".

Jadi tampaknya ada keinginan di antara pengembang perpustakaan standar dan anggota komite bahwa, setidaknya di masa mendatang, konten std::experimentalnamespace harus benar-benar bersifat "eksperimental", dan tidak boleh dianggap remeh bahwa sesuatu distd::experimental akan membuatnya menjadi standar C ++.

Dan tidak, sejauh yang saya mengerti, terserah vendor perpustakaan standar, apakah mereka menyediakan implementasi untuk berbagai fitur di dalamnya std::experimental.

— Joseph Thomson
sumber
47
10 tahun setelah saya pertama kali membaca namanya, fakta bahwa pengelola STL Microsoft bernama STL masih membuat saya terkekeh.
— Jörg W Mittag
19
@ JörgWMittag Anda harus bertemu dengan pengelola kompiler mereka, Michael Sam Victor Collins
— MM
28

"Eksperimental" adalah istilah yang agak dibesar-besarkan. The filesystemperpustakaan berasal Boost dan pergi melalui beberapa iterasi sana, sebelum diajukan ke ISO.

Namun, standar ISO sengaja dibuat sangat konservatif. Menyebutnya eksperimental berarti ISO secara eksplisit tidak menjanjikan bahwa penamaan akan stabil; sangat jelas bahwa Anda perlu mengalamatkan ulang kode Anda suatu saat nanti. Namun mengetahui ISO, kemungkinan besar akan ada panduan caranya.

Adapun kompatibilitas antara kompiler, diharapkan itu masuk akal. Tetapi akan ada kasus sudut (pikirkan jalur relatif drive Windows misalnya), dan itulah mengapa standar masa depan dapat merusak kode yang ada. Idealnya, ini akan merusak kode Anda jika dan hanya jika Anda bergantung pada casing sudut itu, tetapi itu bukan jaminan.

— MSalters
sumber
8

Mungkin ada lebih banyak hal yang perlu ditanyakan.

Beberapa hal yang perlu diperhatikan:

  • Seberapa multiplatform proyek Anda? Jika hanya ada satu kompiler yang terlibat, maka Anda dapat memeriksa implementasinya dan rekam jejaknya untuk memutuskan. Atau tanya mereka!

  • Seberapa besar basis kode Anda? Seberapa besar dampak perubahan?

  • Seberapa mendasar bagi proyek Anda fitur-fitur yang disediakan oleh API / library / feature?

  • Apa alternatifnya?

    • Gunakan fitur eksperimental, lalu sesuaikan kode dengan modifikasi ketika / jika menjadi standar. Mungkin semudah menghapus experimental::, atau sesulit solusi paksa.
    • Tambahkan lapisan abstraksi (komentar Serge Ballesta). Jika fitur eksperimental berubah, penulisan ulang Anda diisolasi. Untuk fitur standar, ini mungkin berlebihan (std :: filesystem sudah menjadi lapisan abstraksi ...).
    • Gunakan API / perpustakaan lain. Pertanyaan yang sama: kedewasaan? ketahanan? stabilitas? portabilitas? kemudahan penggunaan? fitur?
  • Dalam kasus std :: filesystem (atau TS jaringan), ada boost :: filesystem (resp. Boost :: asio) sebagai alternatif atau fallback, jika experimentalsalah satu gagal atau menghilang.
— Pablo H.
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.