4

最大 80 列未満に収まるコード行を記述しようとしています。したがって、変数の型を完全に修飾することは本当に必須なのだろうか? 次の実装を想定しています。

//Baz.h
namespace loggingapi {
namespace attributes {
    class Baz {};
}} // namespaces

// Bar.h
namespace loggingapi {
    namespace attributes {
        class Baz; // forward declare Baz.
    }

    class Biz {
        int f(Baz* b);
    };
} // namespaces

関数パラメーターの型を宣言するには、複数の方法がありますか?

  • a)int f(Baz* b);
  • b) またはint f(attributes::Baz* b);
  • c) またはint f(loggingapi::attributes::Baz* b);
  • d) またはint f(::loggingapi::attributes::Baz* b);

上記のリストで、どの定義がコンパイラにとってより明確/曖昧ですか?

注: 次の実装では、名前空間/パラメーター/クラス/関数名を短縮できないと想定する必要があります。

4

5 に答える 5

3

バリアントe ?

namespace loggingapi {
    namespace attributes {
        class Baz; // forward declare Baz.
    }

    class Biz {
        typedef attributes::Baz Baz;
        // C++ 11 alternative
        // using Baz = attributes::Baz;

        int f(Baz* b);
    }
} // namespaces

エイリアシングができることを忘れないでください...

于 2012-10-05T06:42:33.180 に答える
2

私はb)バリアントを使用します。私の理由は次のとおりです。

  • 開発者は自分が現在どの名前空間にいるのかを知っていると仮定します。したがって、開発者は を参照するときにclass Biz、このクラスがloggingapi名前空間にあることを認識している必要があるため、明示的に記述する必要はありません。
  • 一方、 a)Bazバリアントは、とBizが実際には異なる名前空間にあることを示す必要があるため、十分に明確ではありません。また、コンパイラは名前空間を探しますが、そこにないため、compileにはなりません。Bazloggingapi
于 2012-10-05T06:39:29.253 に答える
1

(b) を選択する必要があります。より柔軟です。関連する型を新しい名前空間またはプロジェクトに移動または (ガスプ) カット アンド ペーストすることにしfた場合、(b) を使用すると、宣言の構造が内部的に一貫したままになります。

囲まれたコードに影響を与えることなく、外側のラッピング名前空間を追加、削除、または名前変更することを選択できます。

于 2012-10-05T06:42:05.147 に答える
1

h ファイルでは、完全修飾名を使用して、クライアント コードが曖昧になるのを防ぐことをお勧めします。.cpp ファイルでは、名前の衝突がない限り、省略表記を使用できます。

于 2012-10-05T06:45:07.100 に答える
0

コンパイラにあいまいさがあれば、間違いなくエラーが報告されます。

質問は、非常に主観的な人間の読者に関するものであるべきだと思います。
命名規則は、

  1. あらかじめ決められたコーディング スタイル
  2. 関数を宣言する場所f()

他に明確な選択肢はありません。両方のエンティティが同じものに属している場合はnamespace、名前から少なくともその部分を省略します。

namespace loggingapi {
    namespace attributes {
        class Baz; // forward declare Baz.
    }

    class Biz {
        int f(attribute::Baz* b);
    };      // ^^^^^^^^^^^^^
}
于 2012-10-05T06:41:48.973 に答える