C++ 標準ライブラリでこれまでに見た他のすべては、std
名前空間にあります。からのものを使用するstd::chrono
と、通常、1 行あたり 80 文字の制限を超えますが、これは問題ではなく、単に不便です。
ここで私の簡単な質問: chrono ヘッダーに独自の名前空間があるのはなぜですか?
私はクロノ提案の筆頭著者でした。冗長性のために、サブ名前空間は私の最初の選択ではありませんでした。using namespace std::chrono
施設を利用するたびに、自分で書いていることに気づきます。
しかし、これは非常に物議を醸す提案でした。そして、私の共著者の何人かを含む多くの人々は、サブ名前空間が適切であると強く感じました。私たちは妥協する必要があるスペースにいたか、米国議会と同じように行き詰まってしまったので、サブ名前空間に強く反対しませんでした。:-)このようなデッドロックの結果は、おそらくC11timespec
でした。
boostは、stdよりもはるかに積極的にサブ名前空間を実験しており、このペーパーの主要な作成者の1人は、クロノが発展したブースト日時ライブラリの作成者でもあります。したがって、それは明らかにサブ名前空間を使用する方向に強く引っ張られるでしょう。
将来的には、サブ名前空間が絶対に必要になる可能性があります。12月の略語を含むカレンダーサービスを追加するとしますdec
。これは直接競合します:
ios_base& dec(ios_base& str);
で<ios>
。したがって、全体として、最初からサブ名前空間を主張しなかったのはおそらく間違っていました。:-)今後、委員会がサブ名前空間を作成する場所と作成しない場所を監視することは興味深いでしょう。
更新(6年後...)
真実は常にフィクションよりも奇妙です...
そこで、名前空間がネストされているので安全だと考えて、の省略形として提案しました。しかし、いいえ、委員会は、潜在的な競合のために、標準化プロセス中に名前を変更することを決定しました。std::chrono::dec
December
chrono
std::chrono::dec
std::chrono::December
では、ネストされた名前空間はそれだけの価値がありますか?
知らない。この更新はデータポイントであり、意見ではありません。
など、他の名前空間もありますstd::placeholders
。std
最終的に、委員会は C++03 でサブ名前空間を採用しませんでしたが、現在、名前空間が大幅に過負荷になっていることは痛々しいほど明らかです。そのため、C++14 向けの多くのライブラリ提案では、コンポーネントの大規模な組織用にサブ名前空間を使用することを期待しています。