私は C++ から Java と C# に切り替えましたが、名前空間/パッケージの使い方はそちらの方がはるかに優れていると思います (構造が適切です)。その後、C++ に戻って、同じように名前空間を使用しようとしましたが、ヘッダー ファイル内で必要な構文がひどいものでした。
namespace MyCompany
{
namespace MyModule
{
namespace MyModulePart //e.g. Input
{
namespace MySubModulePart
{
namespace ...
{
public class MyClass
以下も私には奇妙に思えます (深いインデントを避けるため):
namespace MyCompany
{
namespace MyModule
{
namespace MyModulePart //e.g. Input
{
namespace MySubModulePart
{
namespace ...
{
public class MyClass
{
上記のことをもっと短く表現する方法はありますか？私は次のようなことを言い忘れています
namespace MyCompany::MyModule::MyModulePart::...
{
public class MyClass
アップデート
はい、Java/C# と C++ では使用法の概念が異なると言う人もいます。本当ですか? (動的な) クラス読み込みは名前空間の唯一の目的ではないと思います (これは非常に技術的に根拠のある観点です)。読みやすさと構造化のために使用しない理由はありません。たとえば、「IntelliSense」を考えてみてください。
現在、名前空間とそこにあるものとの間にはロジックや接着剤はありません。Java と C# では、これがはるかにうまく行われています...<iostream>名前空間をインクルードして持つのはなぜstdですか? ロジックはインクルードするためにヘッダーに依存する必要があると言うなら、なぜ #include は や のような「IntelliSense」対応の構文を使用しないのです#include <std::io::stream>か<std/io/stream>? デフォルトのライブラリに構造化が欠けていることは、Java/C# と比較した C++ の弱点の 1 つだと思います。
競合を回避するための一意性が 1 つのポイントである場合 (これは C# や Java のポイントでもあります)、プロジェクト名または会社名を名前空間として使用するのが良いアイデアだと思いませんか?
一方で、C++ は最も柔軟性が高いと言われていますが... 誰もが「これをやらないほうがいい」と言っています。C++ は多くのことができるように思えますが、多くの場合、C# と比較すると、最も簡単なことでさえ構文がひどいです。
アップデート2
ほとんどのユーザーは、2 レベルより深いネストを作成するのは無意味だと言います。では、Win8 開発における Windows::UI::Xaml および Windows::UI::Xaml::Controls::Primitives 名前空間はどうでしょうか。Microsoft の名前空間の使用は理にかなっており、確かに 2 レベルより深いと思います。より大きなライブラリ/プロジェクトには、より深いネストが必要だと思います (ExtraLongClassNameBecauseEveryThingIsInTheSameNameSpace のようなクラス名は嫌いです... すべてをグローバル名前空間に配置することもできます)。
アップデート3 - 結論
ほとんどの人は「やらないほうがいい」と言いますが、boost でも 1 レベルや 2 レベルよりも深いネストがあります。確かにライブラリではありますが、再利用可能なコードが必要な場合は、自分のコードを他の人に提供するライブラリのように扱ってください。私は、名前空間を使用して検出するために、より深いネストも使用しています。
ベストアンサー1
C++17 ではネストされた名前空間の定義が簡素化される可能性があります。
namespace A::B::C {
}
は以下と同等である
namespace A { namespace B { namespace C {
} } }
cppreferenceの名前空間ページの(8)を参照:
http://en.cppreference.com/w/cpp/language/名前空間