問題タブ [argument-dependent-lookup]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
309 参照

c++ - 「ジェネリック関数」の戻り型の判別

仮に、double型やユーザー定義型を含む数値のような型で使用できる汎用ライブラリを開発したいとします。私が今直面している問題は、次のような関数テンプレートの戻り型を作成する方法がわからないことです。

using宣言を使用すると、プリミティブ型に対してこの関数テンプレートの本体が機能します。これは、プリミティブ型に名前空間が関連付けられていないためです(したがって、ADLはありません)。しかし、ユーザー定義型の作成者が独自のabs関数を提供する場合に備えて、transmogrifyで特殊なabs関数を使用したいと思います。単純に使えない

std :: absがスコープ内にないため、これはたとえばdoubleに対しては機能しないためです(私が知る限り)。しかし、書く

ADLを無効にします。ただし、ADLを無効にすることはできません。また、特殊なabs関数によって返される値は、タイプTではなく、他のタイプである可能性があります。

(a)ADLを維持し、(b)特殊なabsを提供しない型のデフォルト関数(この場合はstd :: absなど)にフォールバックしながら、戻り型の問題を解決する方法に関するアイデア。

0 投票する
1 に答える
2448 参照

c++ - C++ での引数依存ルックアップ

これはどのように作動しますか?ADLと関係ありますか?

なぜ私が次のようなものを使用できないのか誰か教えてもらえますか

0 投票する
2 に答える
1363 参照

c++ - ADL が「std 名前空間」の関数よりも優先されるのに、ユーザー定義の名前空間の関数と等しいのはなぜですか?

デモ用に ADL の 2 つのスニペットがあります。どちらのスニペットも VC10、gcc、comeau C++ コンパイラでコンパイルされており、結果は 3 つすべてで同じです。

<1>ユーザー定義の名前空間のディレクティブを使用することに対する ADL:

コンパイル結果:

これは、ADL が通常のルックアップ結果よりも優先されず、ADL が第 2 級市民ではないため、ADL 検索結果が通常の (非 ADL) 条件のないルックアップと結合されるためです。だからこそ、私たちはあいまいさを持っています。

<2> std 名前空間のディレクティブを使用することに対する ADL:

これは正常にコンパイルされます。

その結果、コンパイラは ADL の結果を選択します (std::swap よりも優先されます)。つまりN::swap()、「ポイント 1」で呼び出されます。「ポイント 1」がない場合 (たとえば、その行をコメントアウトした場合) のみ、コンパイルはstd::swap代わりにフォールバックを使用します。

この方法は、 を上書きする方法として多くの場所で使用されていることに注意してくださいstd::swap。しかし、私の質問は、ADL が「std 名前空間」(case2) よりも優先されるのに、ユーザー定義の名前空間関数 (case1) と同等と見なされるのはなぜですか?

そう言っているC++標準の段落はありますか?

================================================== =============================== 有用な回答を読んだ後に編集すると、他の人に役立つかもしれません。

だから私はスニペット1を微調整しました&今ではあいまいさがなくなり、オーバーロードの解決を行うときに非テンプレート関数を明らかに優先してコンパイルします!

スニペット 2 も微調整しました。あいまいさを楽しみのために表示するためです。

gcc と comeau はどちらも、予想どおりあいまいさを示しています。

ところで、いつものように愚かな VC10 は、「using std::swap」を削除しない限り、これを問題なく通過させます。

もう少し書く必要があります: C++ のオーバーロードはトリッキーになる可能性があります (C++ 標準では 30+ ページ) が、付録 B には非常に読みやすい 10 ページがあります...

すべての素晴らしい入力に感謝します。これで明確になりました。

0 投票する
1 に答える
130 参照

c++ - 通常の無修飾検索と引数依存の名前検索(ADL)

非修飾名ルックアップ、「通常の非修飾ルックアップ」および「引数依存の名前ルックアップ」(ADL) について、どちらが最初に発生するかを標準で見つけることができません。

繰り返しますが、どちらもオーバーロード候補セットに何かを追加しようとしていますが、順序は問題ではないようです。しかし、どちらが最初に起こるかを知ることはまだ良いでしょう.

ありがとう

0 投票する
1 に答える
239 参照

c++ - ADL によって選択されたオーバーロードをオーバーライドする

私はoperator<<自分のバージョンに置き換えたい欠陥のあるライブラリを使用しています。これは、ADL がライブラリの名前空間の引数のメンバーシップに基づいてオーバーロードを選択するイディオムに従います。operator<<代わりにC++ に自分自身を選択させる方法はありますか?

0 投票する
1 に答える
389 参照

c++ - c++: テンプレートでの非修飾名ルックアップのコンテキスト

do_run の解決について標準を調べてみたところ、「非修飾名ルックアップ (3.4.1) または修飾名ルックアップ (3.4.3) を使用したルックアップの部分では、テンプレート定義コンテキストからの関数宣言のみが見つかりました。 "。コンテキストとは正確には何ですか?

次の例では、do_run(int)何らかの形で を「隠し」do_run(domain::mystruct)、コンパイラはo can't be converted to int. をコメントアウトするdo_run(int)と、do_run(domain::mystruct)に表示されrun、コードがコンパイルされます。この動作は、標準で言及されている「コンテキスト」に関連していますか? 私には両方do_run(int)do_run(domain::mystruct)ように見え、(解決可能な)実行に見えるはずです。

が存在する場合、「コンテキスト」do_run(int)に持ち込むための追加の手順が必要です。do_run(domain::mystruct)次の 3 つの方法があります。

  1. do_run(domain::mystruct)名前空間ドメインに入れます。
  2. do_run(domain::mystruct)名前空間 lib::detailsに入れます。
  3. using ::do_run名前空間 lib::details 内に追加します。

したがって、コンテキストは名前空間 lib::details と名前空間ドメインであると推測しましたか?

コンパイラ VS2010

0 投票する
2 に答える
2270 参照

c++ - iter_swapのポイントは何ですか?

私はただ疑問に思っていました、なぜ誰かがこれを書くのでしょうか:

これの代わりに?

それから私はの実装を調べました、そしてiter_swapもちろん、とにかく、私たちがすでに入っているので、swap代わりにそれだけを使用します。それは私を次の質問に導きます:std::swapnamespace std

なぜ誰かがこれを書くのでしょうか:

これの代わりに?

ここで見落としている重要な違い/問題はありますか?

0 投票する
2 に答える
293 参照

c++ - C++11 がこのような名前検索をサポートしないのはなぜですか?

コンパイラは不平を言います:error C2065: 'X' : undeclared identifier

コンパイラーはコンストラクターのパラメーターの型が何であるかを認識しているため、X を引数として渡すと、コンパイラーはそれが有効な引数であることを認識する必要があります。

これが ADL (Argument-dependent Name Lookup、Koenig Lookup とも呼ばれる) ではないことはわかっていますが、便利でかなり便利だと思います。次のように書く必要がないからです。

ADL ルールはそのような場合に一般化されるべきだと思います。

私は正しいですか?

0 投票する
1 に答える
71 参照

c++ - 別の関数からADLによって関数を呼び出す

一般的な状況でADLによってタイプがどのように検出されるかに関する質問があります。具体的には、コンパイル時にADLによって検出される関数の存在を確認する必要がある「ジェネリック」コードがいくつかあります。例えば:

'sizeoftrick'を使用してこのADL関数の存在を確認するトレイトクラスがあります。

トレイトクラス/sizeofトリック自体は重要ではありません(興味があれば、C ++テンプレートメタプログラミングの本で詳細を見つけることができます)。むしろ、問題は、DoSomethingが定義されている(任意の)型の#includeのに#includeしない限り、この型の特性がコンパイルされないことです。

または、DoSomething関数宣言を使用してダミークラスを作成します。

そしてそれを(直接またはDummy.h経由で)HasDoSomething.hに含めます。#includesの順序を強制したり、冗長なコードを挿入したりして、このようなADLルックアップを開始するのは理想的ではないようです。誤解したり、間違ったことをしたりしていませんか?