最新のC ++の実験的な機能は、長期的なプロジェクトに対して信頼できますか？

Question 1

現在C ++ 11/14を使用しているプロジェクトがstd::filesystemありますが、C ++ 17でのみ使用可能なのようなものが必要であるため、現在使用する機会がありません。ただし、現在のコンパイラではstd::experimental::filesystem。として使用できるようです。将来、次のようなものを追加できると仮定して、実験的な機能を使用することをお勧めしますか？

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

私の懸念は次のとおりです。

1.すべての準拠コンパイラが同じ実験機能を備えていることが保証されていますか？

2.実験的な機能は、信頼性を低下させる大きな変更が発生する傾向がありますか？

たぶん、疑問に思うことがもっとあります。なぜそれらを使用する必要があるのですか、または使用しないのですか？私は新しいプロジェクトに戸惑い、何を決めるのかわかりません。

Question 2

すべての準拠コンパイラが同じ実験的機能を備えていることが保証されていますか？

いいえ、実験的な機能はオプションです。

実験的な機能は、信頼性を低下させる大きな変更が発生する傾向がありますか？

はい、C ++委員会は機能を放棄することを決定したり、標準化の過程で機能の変更を余儀なくされる欠陥が発生したりする可能性があります。

一般に、実験的な機能に依存することはお勧めできません。実験的特徴は、まさにその言葉が言うことです（つまり、実験するため）。

Question 3

聴衆の誰かが、CppCon 2016（YouTube）での「C ++標準ライブラリパネル」の講演experimental中に、名前空間内でユーザーが何かを使用するのを怖がらせる可能性について質問しました。

[std::experimental名前空間の内容]は本番環境に対応していると思いますか。それは、今後3年間は実質的に本番環境に対応できるという議論ができるということでしょうか。おそらく、3年後にコードを変更する必要があるのではないでしょうか。

Michael Wong（SG5およびSG14の議長であり、Concurrency TSの編集者）が最初に質問に答えました。

委員会内では、実質的に生産準備が整っているという強いコンセンサスがあると思います。前にも言ったように、ほとんどの場合、99％がエアドロップインされます。それがあなたの使用を妨げるものではないことを確認したいと思います。ライブラリシステム全体の残りの部分を邪魔しないように、大きな機能、機能の大きなグループをこのようなコンテキストに配置する理由を理解できますが、それによって使いやすくなります。これで、コンセプトの特定のフラグを使用してGCCをオンにできるようになりました。これにより、実際にセグメント化が容易になります。

その後、Alisdair Meredith（元LWG議長）がフォローアップしました。

私はここで反対の立場を取るつもりです。ハーブ[サッター]が標準グループであるWG21の招集者として言ったことの1つは、TSの道を歩み始めたとき、何かを前に進めることができなくなるまで、TSが成功するとは思っていなかったからです。つまり、私たちは十分に実験的ではなく、TSを何に使用するかについて十分に野心的ではありません。私たちは本当にそれを望んでいますexperimentalはい、これらのことは変更される可能性があり、私たちはそれに拘束されておらず、物事を間違える可能性があることを示唆しています。これは、私たちができる限り野心的で到達できると考えるものに対する障壁を下げるためです[...]現在、標準は3年のリリースサイクルにあるようですが、実際に実験的な機能を追加することで、はるかに野心的なはずです。 TSに、そしておそらく物事をより迅速にメインスタンダード自体に進めます。しかし、繰り返しになりますが、これは、次の数回の[C ++標準委員会]会議で議論する楽しいトピックになります。

Stephan T. Lavavej（MicrosoftのSTL実装のメンテナー）が最後に応答しました。

インターフェイスの実験性と実装の実験性を区別することが重要です。「本番環境に対応している」とはどういう意味ですか？通常、「本番環境対応」では、実装について話していると思います。[何かのstd::experimental]実装が絶対に[...]防弾になる可能性は十分にあります。[...] <random>TR1のヘッダーのようなもの[それは]本当に、TR1で本当に素晴らしかった、そしてあなたはそれの完全に防弾の実装を持つことができたかもしれない、しかしインターフェースがかき回されたことがわかった実質的に[リリース前] C ++ 11と[...]当時私たちが今何をしているのかを知っていればexperimental、「ねえ、多分あなたはしたくないかもしれない」という人々へのより良い合図だったでしょう。使用するstd::experimental::variate_generator なぜなら、ハハ、C ++ 11 "で消えてしまうからです。

したがって、標準ライブラリの開発者と委員会のメンバーの間には、少なくとも将来的には、std::experimental名前空間の内容が本質的に真に「実験的」であり、std::experimental意志のあるものが当然のことと見なされるべきではないという要望があるようです。それをC ++標準にします。

いいえ、私が理解している限り、内のさまざまな機能の実装を提供するかどうかは、標準ライブラリベンダー次第ですstd::experimental。

Question 4

「実験的」は少し誇張された用語です。filesystemライブラリは、ブーストの起源とISOに提出される前に、そこに数回の反復を経ました。

ただし、ISO規格は意図的に非常に保守的です。それを実験的と呼ぶことは、ISOが命名が安定することを明示的に約束しないことを意味します。将来、コードのアドレスを変更する必要があることは十分に明らかです。しかし、ISOを知っていると、その方法についてのガイダンスがある可能性があります。

コンパイラ間の互換性については、合理的であると期待してください。しかし、コーナーケースがあり（たとえば、Windowsドライブ相対パスを考えてください）、それが将来の標準が既存のコードを壊す可能性がある理由です。理想的には、そのコーナーケースに依存している場合にのみコードが破損しますが、それは保証ではありません。

Question 5

たぶん、疑問に思うことがもっとあります。

考慮すべきいくつかのポイント：

あなたのプロジェクトはどのくらいマルチプラットフォームですか？関係するコンパイラが1つしかない場合は、その実装と実績を調べて決定できます。または彼らに聞いてください！
コードベースの大きさはどれくらいですか？変更の影響はどのくらいですか？
API /ライブラリ/機能によって提供される機能は、プロジェクトにとってどの程度基本的ですか？
選択肢は何ですか？
- 実験的な機能を使用し、標準化された場合にコードを変更に適合させます。削除するのと同じくらい簡単な場合もあれば、experimental::回避策を強制するのと同じくらい難しい場合もあります。
- 抽象化レイヤーを追加します（Serge Ballestaコメント）。実験的な機能が変更された場合、書き換えは分離されます。標準機能の場合、それはやり過ぎかもしれません（std :: filesystemはすでに抽象化レイヤーです...）。
- 別のAPI /ライブラリを使用してください。同じ質問：成熟度？堅牢性？安定？移植性？使いやすさ？特徴？
std :: filesystem（またはネットワーキングTS）の場合、experimental失敗または消失した場合の代替またはフォールバックとして、boost :: filesystem（またはboost :: asio）があります。