0

以上のメリットはnamespace alias何#defineですか？

namespace NS1{
    namespace NS2 {
        namespace NS3
        {
            void fun() {
                std::cout << "Understanding namespace alias\n";
            }
        }
    }
}

#define NS NS1::NS2::NS3
//over
namespace NS=NS1::NS2::NS3;
4

3 に答える 3

3

エイリアスを使用すると、NS シンボルがコンパイラに認識されるようになります。マクロを使用すると、文字列が見つかるたびに置換されます。したがって、NS という名前のローカル変数がある場合、それは NS1::NS2::NS3 に置き換えられますが、これはほとんど望んでいません。

于 2013-02-19T11:35:16.083 に答える
2

daramarakが言ったことを拡張するために、名前空間エイリアスは構文とセマンティクスを尊重します。し#defineません。名前空間エイリアスは、コンパイラがのようなものに遭遇した場合にのみ開始されますがNS::func()、#define一方で、完全に鈍いツールであり、または、または、のようなステートメントを認識してマングルNS()しint NS=7ますnamespace NS=NS1::NS2::NS3。そして、私を信じてください、それがそれを壊すとき、あなたは完全に紛らわしいエラーメッセージを受け取るでしょう。

于 2013-02-19T11:41:37.753 に答える
2

#define に対する名前空間エイリアスの利点は何ですか?

define の一般的な欠点がここに当てはまります: プリプロセッサはコンパイル前にソースを置き換えます。これにより、多くの (大なり小なり) 問題が発生します。

  • デバッガーで使用しようとするNS::funと、デバッガーは NS 名前空間がないことを通知します (コンパイラーが実際にシンボルを見たことがないため)。

  • 名前空間内のエンティティに起因するエラー メッセージは、(クライアント コードで) 名前空間を見ていないことがわかっている場合を除き、ソース コードで (どのように検索しても) 見つからないトークンを含むエラー メッセージを生成します。しかし、名前空間のように見える定義で。

さらに、#define-d シンボルは名前空間に属しません。これは、いったん#define NSNS シンボルをソース コードの他の場所に置くことができなくなることを意味します (プリコンパイラが何も言わずに切り替えを行うため)。つまり、次のようには言えません。

namespace client_code // namespace where NS should not be visible
{
    int NS = 0; // compiler tries to compile "int NS1::NS2::NS3 = 0;",
                // knowing that NS3 is a namespace
}

クライアント コードが独自のものである場合は、名前を避けるだけでよいので問題ありません (ただし、そうしなければならない理由には言い訳はありません)。

他の誰かが使用するヘッダー ファイル/ライブラリを作成している場合は、少なくとも、「クライアント コードはこれらおよびこれらの名前を使用できない」という既知の制限のリストを提供する必要があります。

于 2013-02-19T12:18:41.007 に答える