問題タブ [argument-dependent-lookup]

次のプログラムを検討してください。

私のコンパイラ (gcc 4.3.3) は、size の呼び出しがあいまいであるため、プログラムをコンパイルしません。名前空間 NS2 は、クラス tmpl の size 呼び出しの関連する名前空間のセットに追加されたようです。ISI 標準の Koenig Lookup に関するセクションを読んだ後でも、この動作が標準に準拠しているかどうかはわかりません。それは...ですか？サイズ呼び出しを NS3 プレフィックスで修飾せずに、この動作を回避する方法を知っている人はいますか?

前もって感謝します！

グラフィカル モデリング ツールに慣れ親しんでいる私は、アーキテクチャ記述言語 (ADL) の概念について最近考えました。アーキテクチャを包括的に文書化するために、テキスト形式でアーキテクチャを記述します。

このアプローチには、グラフィカル エディターとテキスト エディターを常に切り替える必要のない 1 つの場所に格納されたアーキテクチャの正式な定義であるため、利点があります。アーキテクチャを記述するTeXの方法の一種。

少し調べてみましたが、かなり古い研究資料しか見つかりませんでした。

ADL を生産的に使用した経験はありますか? 何が機能し、何が機能しないのですか?

ADL からのドキュメント生成をサポートするツールセットはありますか? アーキテクチャのレンダリング イメージ、コンポーネントとインターフェイス、およびコンポーネント階層の説明を含めますか? そして、おそらくそれを使用して動的な動作を説明することさえありますか?

複数の可能性がある場合、C ++コンパイラはどの関数/メソッドを呼び出すかをどのように決定しますか？私の特定のケースでは、C ++ランタイムの標準の無料機能があり、次のようなテンプレート化された無料のバリアントもあります。

次のコードを使用してこれをテストしました。

これをコンパイルして実行すると、mallocの呼び出しがテンプレート化されたバリアントに正しく置き換えられているようです。ここまでは順調ですね。

ただし、freeの呼び出しはテンプレート化されたバリアントに置き換えられず、標準のC++関数が引き続き呼び出されます。

C ++コンパイラは、優先するバリアントを決定するためにどのようなルールを使用しますか？これはケーニッヒルックアップルールに関連していますか？

注：#defineを使用しても問題が解決しないため、この代替方法を試しました（Cマクロ（#define）を使用して呼び出しを変更する方法を参照してください。プロトタイプは変更しないでください）。

n3092を見ると、§6.5.4で、範囲ベースのforループと同等であることがわかります。次に、何に等しいかを言い続け__beginます__end。それは配列と他のタイプを区別します、そして私はこれが冗長であると思います（別名混乱します）。

それは、配列タイプについて__begin、__endあなたが期待するものであると言っています：最初へのポインタと最後から1つへのポインタ。次に、他のタイプの場合、__beginおよびはADLでとに__end等しくなりbegin(__range)ます。§24.6.5で定義されているを見つけるために、end(__range)名前空間stdが関連付けられています。std::beginstd::end<iterator>

ただし、との定義を見るstd::beginとstd::end、これらは両方とも配列とコンテナタイプに対して定義されています。また、配列のバージョンは上記とまったく同じです。最初のポインタ、最後の1つを指すポインタです。

std::begin他のタイプに与えられた定義が同様に機能するのに、なぜ配列を他のタイプと区別する必要があるのstd::endですか？

_{便宜上、いくつかの要約引用符：}

§6.5.4範囲ベースのforステートメント

— _RangeTが配列型の場合、begin-exprとend-exprはそれぞれ__rangeと__range + __boundです。ここで、__boundは配列のバインドです。_RangeTが不明なサイズの配列または不完全な型の配列である場合、プログラムの形式が正しくありません。

—それ以外の場合、begin-exprとend-exprはそれぞれbegin（__ range）とend（__range）であり、beginとendは引数依存のルックアップ（3.4.2）でルックアップされます。この名前空間のルックアップでは、名前空間stdは関連付けられた名前空間です。

§24.6.5範囲アクセス

戻り値：配列。

戻り値：配列+N。

C ++仕様のどの部分が、引数に依存するルックアップが、関連付けられた名前空間のセットで関数テンプレートを見つけることを制限していますか？言い換えると、main以下の最後の呼び出しがコンパイルに失敗するのはなぜですか？

少し前に、引数依存ルックアップのいくつかの落とし穴を説明した記事を読みましたが、もう見つかりません。アクセスしてはいけないものにアクセスすること、またはそのようなものにアクセスすることについてでした。そこで、ここで質問したいと思います: ADL の落とし穴は何ですか?

私は2つの機能を持っています:

と

呼び出しを考えると：

どうやら、fooスタックベースの正しく宣言された配列での呼び出しは期待どおりに動作しますfooが、リテラル "liter. : Hello World" での呼び出しはそうではありません。

1 つのオーバーロードを他のオーバーロードよりも選択するために、シンボル ルックアップが従う規則は正確には何ですか?

宣言された配列と文字列リテラルの動作が異なるのはなぜですか?

ありがとう ！

編集

目的の結果を得る (つまり、リテラル文字列をfoo(const char (& p)[T_Size])関数に一致させる) 方法は、を削除してvoid foo(const char *p)代わりに追加することです。

この間接化により、テンプレート化された foo は文字列リテラルにより適したものになり、ユーザーは引き続きポインターを使用できます (間接化は最適化されたコンパイル モードで削除されます)。

g++ 4.4.3 でテストしましたが、すべてのコンパイラで同じように動作すると思います。

次のコードを検討してください。

コンパイラは大きく反対しているようです。(MSVC08/10 はノー、GCC<4.5 はイエス、4.5 はノー、sun 5.1 はイエス、インテル 11.1 もイエス、comeau はノー (どちらも EDG))。

「C++ テンプレート - 完全なガイド」によると:

... 関連付けられたクラス内のフレンドのルックアップを含む呼び出しにより、実際にクラスがインスタンス化されると想定されています ... これは、C++ 標準を作成した人々によって明確に意図されていましたが、標準では明確に記述されていません。

標準で関連するセクションが見つかりませんでした。参照はありますか？

次のバリエーションを検討してください。

ここでの重要な問題は、によって注入された実行可能な関数がX<1>ADL 中に表示されるX<0>かどうかです。それらは関連していますか？上記のすべてのコンパイラは、このコードを受け入れますが、Comeau はリラックス モードでのみ受け入れます。これについて標準が何を言わなければならないのかもわかりません。

それについてどう思いますか？

私はこの問題に数回噛まれたので、同僚もそうです。コンパイルするとき

... 2番目の検索をコンパイルするときに、VS9コンパイラが失敗します。これはSTest2、ブースト名前空間で定義された型から継承し、コンパイラがを検出するADLを試行するようにトリガーするためboost::algorithm::find(RangeT& Input, const FinderT& Finder)です。

find(…)明らかな解決策は、呼び出しの前に「 」を付けること::ですが、なぜこれが必要なのですか？グローバル名前空間には完全に有効な一致があるのに、なぜ引数依存のルックアップを呼び出すのですか？誰かがここで理論的根拠を説明できますか？