引数のためのKoenigルックアップ

Question

引数のためのKoenigルックアップの考えは悪いことですか？我々が持っているADLで

：

namespace foo 
{ 
    struct bar {}; 
    void baz(bar); 
} 

baz(foo::bar()); 

そして、なぜ私たちはのようなものはありません。

namespace foo 
{ 
    struct bar {}; 
    void baz(bar); 
} // namespace foo 

foo::baz(bar()); 

Answer 1

重複していない部分に焦点を当てて、なぜfoo::baz(bar());？簡単な理由は、C++では、解析ツリーは常に下から上に処理されるということです。関数名の名前検索は、関数の引数に依存します。オーバーロード解決が引数の型に依存し、戻り型に依存しないのと同じように、別の方法ではありません。

Answer 2

は悪いことでは引数のケーニッヒ・ルックアップのアイデアですか？

絶対にありません。それはあなたが属している非メンバAPIの配置を許可します：あなたの型と同じ名前空間。関数を呼び出すときにユーザーが名前空間を認識することを強いられません。
は、それがstd::sort(std::begin(vec), std::end(vec));

とは対照的に、それはまた、あなたが演算子をオーバーロードする際に持っている必要がありますsort(begin(vec), end(vec));を書くことがいかに便利で考えてみましょう。

そして、私たちのようなものはありません理由：それは簡単に反対よりも曖昧なので

namespace foo 
{ 
    struct bar {}; 
    void baz(bar); 
} // namespace foo 

foo::baz(bar()); 

を。異なる名前空間のbarにfoo::bazがオーバーロードされている場合はどうなりますか？あなたは他のbarでそれを完全に修飾することなくそれを呼び出すことは不可能になります。

Answer 3

Koenigルックアップの議論は悪い考えですか？

全くありません。演算子のオーバーロードのシナリオについて考えてみましょう。ADLは、異なる名前空間で定義された演算子を使用できるようにします。 ADLと

namespace foo 
{ 
    struct bar {}; 
    bar operator+ (const bar& lhs, const bar&rhs); 
} 

、我々はADLなし

foo::bar b1, b2; 
auto b3 = b1 + b2; // natural as operator 

を書くことができ、我々は追記として

auto b3 = foo::operator+(b1, b2); // unnatural 

を記述する必要があり、STLのすべてのオーバーロードされた演算子は、名前空間stdで定義されています。 ADLがなければ、われわれはそれを簡単に呼ぶことさえできる。

さらに、ADLを使用しないと、テンプレートの作成が難しくなります。

template <typename T> 
T add(const T& lhs, const T& rhs) { 
    return What_Namespace::operator+(lhs, rhs); // how to deduce the name of namespace? 
}