Modern C ++ 'ın deneysel özellikleri uzun vadeli projeler için güvenilir midir?

87

Şu anda C ++ 11/14 kullanan bir projem var, ancak std::filesystemsadece C ++ 17'de mevcut olan gibi bir şey gerektiriyor ve bu nedenle şu anda onu kullanma şansım yok. Bununla birlikte, mevcut derleyicimde olarak mevcut olduğunu görüyorum std::experimental::filesystem. Gelecekte aşağıdakilere benzer bir şey ekleyebileceğimi varsayarak deneysel özellikleri kullanmak iyi bir fikir mi?

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

Endişelerim:

1. Tüm uyumlu derleyicilerin aynı deneysel özelliklere sahip olduğu garanti ediliyor mu?

2. Deneysel özellikler, onları güvenilmez kılan büyük değişikliklere yatkın mı?

Belki merak edilecek daha çok şey vardır. Neden kullanmalıyım ya da kullanmamalıyım? Yeni bir proje ile kafam karıştı ve neye karar vereceğimi bilmiyorum.

c++  c++11  portability  c++17  c++-standard-library 
— Kuantum Fizikçisi
kaynak
25
deneysel kelimesi sorularınıza cevap vermiyor mu?
— 101010
6
Esas olarak bir zevk meselesi, ancak kodu karıştırmaktan kaçınırım #idef CXX17. IMHO, taşınabilir yol, dosya sistemiyle ilgili tüm kodu tek bir derleme birimine (bir sınıf olabilir) koymak, onu kodun geri kalan bölümlerinde kullanmak, mevcut C ++ 11/14 standardıyla kodlamaktır. Bunu neden böyle yazdığınızı belgeleyin ve daha sonra bir bakım aşamasında, eğer mantıklıysa, sonunda C ++ 17'ye taşıyın. (orijinal soruya yorum yaparak)
— Serge Ballesta
4
Standarda girmeye aday olarak sadece "deneysel" idi. Kodun kalitesinin bir yansıması değildir.
— Galik
5
"Deneysel" ve son C ++ 17 sürümü arasında epeyce değişiklik oldu, bkz. Belge P0492R1
— Bo Persson
7
Durumunda filesystemsize zaten o C ++ 17'de standardize alır olduğunu bildiğimiz gibi, diğer şeyler daha bunu kullanarak çok daha az risk tabi ve bunun kesin C ++ 17 şartname genel kullanıma açıktır. Yani tek yapmanız gereken, yalnızca experimental::filesystemC ++ 17 spesifikasyonunda bulunan özellikleri kullandığınızdan emin olmaktır . Ve elbette, hedeflenen tüm platformlarınızın experimental::filesystemC ++ 17'yi veya birini desteklediğini bilmelisiniz std::filesystem.
— Howard Hinnant

Yanıtlar:

79
  1. Tüm uyumlu derleyicilerin aynı deneysel özelliklere sahip olacağı garanti ediliyor mu?

Hayır, deneysel özellikler isteğe bağlıdır.

  1. Deneysel özellikler, onları güvenilmez kılan büyük değişikliklere meyilli mi?

Evet, C ++ komitesi bir özelliği terk etmeye bile karar verebilir veya standardizasyon sürecinde bir özelliği değiştirmeye zorlayacak bir kusur ortaya çıkabilir.

Genelde deneysel özelliklere güvenmek iyi bir fikir değildir. Deneysel özellikler, kelimenin tam olarak söylediği şeydir (yani, denemek için).

— 101010
kaynak
2
İkinci noktaya değinerek, lütfen zaten kabul edilmiş, ancak farklı olabilecek özelliklerden bahsettiğimi unutmayın .
— The Quantum Physicist
14
@TheQuantumPhysicist: "Zaten kabul edildi" hileli bir kavram. Herhangi bir şey, daha sonra kaldırılacak bir değişikliğin kabul edilmesiyle herhangi bir zamanda kaldırılabilir ve bu, her standardın başına gelmiştir. Özellik kümesi makul ölçüde güvenilir olmadan önce muhtemelen en azından Taslak Uluslararası Standart'a kadar beklemek isteyeceksiniz.
— Kerrek SB
1
@KerrekSB: Nihai Taslak Uluslararası Standardı, yani FDIS'i mi kastediyorsunuz ? ? Taslak hazırlama oldukça kalıcı bir süreçtir.
— MSalters
1
@MSalters: Hayır, aceleniz varsa DIS muhtemelen yeterince iyidir. Ve yine de bu sefer bir FDIS'imiz olmayabilir.
— Kerrek SB
4
@KerrekSB: C ++ 03 civarında Hollanda Ulusal Organıydım;). SC22 için ISO prosedürlerini ve bir FDIS'e nasıl yanıt verileceğini bilen, ancak neyi bilmeyen bir ulusal sekreterimiz vardı. WG14 delegemiz Randy Marques dışında) SC22 delegelerimizden hiçbiri C ++ hakkında hiçbir şey bilmiyordu. Ve Randy, C ++ 'nın Tanımlı Davranış için gereken tüm
— UB'yi
50

Seyircilerden biri, CppCon 2016'daki ( YouTube ) "C ++ Standart Kitaplık Paneli" sohbeti sırasında , adın experimentalkullanıcıları ad alanı içinde herhangi bir şey kullanmaktan korkutması potansiyeli hakkında bir soru sordu :

Siz [ std::experimentalad alanının içeriğini ] üretime hazır olarak mı düşünüyorsunuz ve bu, önümüzdeki 3 yıl için etkin bir şekilde üretime hazır olduğunu ve belki de kodunuzu 3 yıl sonra değiştirmeniz gereken bir argüman olduğunu düşünüyor musunuz?

Michael Wong (SG5 ve SG14 başkanı ve Concurrency TS editörü) ilk olarak soruyu yanıtladı:

Sanırım komitede pratikte üretime hazır olduğuna dair güçlü bir fikir birliği var. Daha önce de söylediğim gibi, çoğu durumda% 99'u hava damlası oluyor. Kullanmanızın sizin için bir engel olmadığından emin olmak istiyoruz. Neden tüm kütüphane sisteminin geri kalanını rahatsız etmemek için büyük özellikleri, geniş özellik gruplarını böyle bir bağlama koymak istediğimizi anlayabilirsiniz, aynı zamanda onu kullanmanızı kolaylaştırır. Artık GCC'yi belirli bir Kavramlar bayrağıyla açabilirsiniz, bu aslında onu bölümlere ayırmanızı kolaylaştırır.

Alisdair Meredith (LWG'nin eski başkanı) daha sonra takip etti:

Ben burada tam tersi bir pozisyon alacağım. Herb [Sutter] 'ın WG21'in düzenleyicisi olarak söylediği şeylerden biri, standart grup, TS'lerin yolunu belirlediğimizde, TS'lerin bir şeyi ileri götürmeyi başaramayıncaya kadar başarılı olacağını düşünmedi, çünkü bu Yeterince deneysel olmadığımız anlamına geliyor, TS'leri ne amaçla kullandığımız konusunda yeterince hırslı değiliz. Bunu gerçekten istiyoruzexperimentalbir ipucu olmak gerekirse, evet, bu şeyler değişebilir, biz buna bağlı değiliz ve yanlış anlayabiliriz. Bu, iddialı olduğunu düşündüğümüz ve elimizden geldiğince ulaşabileceğimiz şeyler için engelimizi azaltmaktır [...] Şimdi standart üç yıllık bir sürüm döngüsünde görünüyor, gerçekten deneysel özellikler koymak konusunda çok daha hırslı olmalıyız TS'ye ve belki de işleri daha hızlı şekilde ana standardın kendisine doğru ilerletmek. Ancak yine, bu önümüzdeki birkaç [C ++ standart komite] toplantısında tartışmak için eğlenceli bir konu olacak.

Stephan T. Lavavej (Microsoft'un STL uygulamasının koruyucusu) yanıt veren son kişi:

Arayüzün deneyselliği ile uygulamanın deneyselliği arasında bir ayrım yapmak önemlidir, çünkü "üretime hazır" dediğinizde bu ne anlama geliyor? Genellikle, "üretime hazır", uygulama hakkında konuşurken bunu düşünürsünüz. [Bir şeyin std::experimental] gerçekleştirilmesinin kesinlikle [...] kurşun geçirmez olması oldukça olasıdır . [...] [...] <random>TR1'deki başlık gibi bir şey , TR1'de gerçekten çok güzel [öyleydi] ve bunun kesinlikle kurşun geçirmez bir uygulamasına sahip olabilirdiniz, ancak arayüzün karışık olduğu ortaya çıktı büyük ölçüde [yayımlanmadan önce] C ++ 11 ve [...] o zamanlar ne yaptığımızı bilseydik, experimentalinsanlara "Hey, belki de istemezsin kullanımstd::experimental::variate_generator çünkü ha-ha, C ++ 11 "de yok olacak.

Öyleyse öyle görünüyor ki, standart kütüphane geliştiricileri ve komite üyeleri arasında, en azından gelecekte, std::experimentalad alanının içeriğinin doğası gereği gerçekten "deneysel" olması gerektiği ve bir şeyin std::experimentalirade edileceğine kesin gözüyle bakılmamalıdır. bunu C ++ standardına getirin.

Ve hayır, anladığım kadarıyla, içindeki çeşitli özellikler için uygulamalar sağlayıp sağlamadıkları standart kitaplık satıcılarına kalmış std::experimental.

— Joseph Thomson
kaynak
47
Adı ilk okuduktan 10 yıl sonra, Microsoft'un STL bakımcısının adının STL olması beni hala kıkırdatıyor.
— Jörg W Mittag
19
@ JörgWMittag derleyici bakımcısı Michael Sam Victor Collins ile tanışmalısınız
— MM
28

"Deneysel" biraz abartılı bir terimdir. filesystemKütüphane Boost kökenli ve ISO sunulmadan önce, orada birkaç tekrarlamadan geçti.

Ancak, ISO standartları kasıtlı olarak çok muhafazakar. Bunu deneysel olarak adlandırmak, ISO'nun açıkça adlandırmanın kararlı olacağına dair söz vermediği anlamına gelir; Gelecekte kodunuzu yeniden adreslemeniz gerekeceği çok açıktır. Ancak ISO'yu bilmek, nasıl yapılacağına dair bir rehber olması muhtemeldir.

Derleyiciler arasındaki uyumluluğa gelince, bunun makul olmasını bekleyin. Ancak önemli durumlar olacaktır (örneğin, Windows sürücüye bağlı yolları düşünün) ve tam da bu nedenle gelecekteki bir standart mevcut kodunuzu bozabilir. İdeal olarak, yalnızca ve ancak o köşe kasasına bağlı olsaydınız kodunuzu kırardı, ancak bu bir garanti değil.

— Malters
kaynak
8

Belki merak edilecek daha çok şey vardır.

Dikkate alınması gereken birkaç nokta:

  • Projeniz ne kadar çok platformlu? Katılan yalnızca bir derleyici varsa, uygulanmasını inceleyebilir ve karar vermek için kayıtlarını takip edebilirsiniz. Veya onlara sorun!

  • Kod tabanınız ne kadar büyük? Değişikliklerin etkisi ne kadar olacaktır?

  • API / kitaplık / özellik tarafından sağlanan özellikler projeniz için ne kadar temeldir?

  • Alternatifler neler?

    • Deneysel özelliği kullanın, ardından kodu standart hale geldiğinde / olduğunda değişikliklere uyarlayın. Silme kadar kolay experimental::veya geçici çözümleri zorlamak kadar zor olabilir.
    • Bir soyutlama katmanı ekleyin (Serge Ballesta yorumu). Deneysel özellik değişirse, yeniden yazmalarınız izole edilir. Standart bir özellik için aşırı olabilir (std :: dosya sistemi zaten bir soyutlama katmanıdır ...).
    • Başka bir API / kitaplık kullanın. Aynı sorular: olgunluk? sağlamlık? istikrar? taşınabilirlik? kullanım kolaylığı? özellikleri?
  • Std :: dosya sistemi (veya ağ oluşturma TS) durumunda, experimentalbaşarısız olursa veya kaybolursa , alternatif veya geri dönüş olarak boost :: dosya sistemi (ayrıca boost :: asio) vardır .
— Pablo H
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.