整数->ポインター変換規則

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

void f(double p) {}
void f(double* p) {}

int main()
{ f(1-1); return 0; }

MSVC 2017はそれをコンパイルしません。と1-1同じ0であるため、あいまいなオーバーロードされた呼び出しがあることを示しているため、に変換できますdouble*。他のトリックは、のような0x0、0Lまたはstatic_cast<int>(0)、いずれかの動作しません。を宣言しconst int Zero = 0て呼び出しf(Zero)ても同じエラーが発生します。それは場合にのみ正しく動作Zeroではありませんconst。

同じ問題がGCC 5以下に当てはまるようですが、GCC 6には当てはまりません。これがC ++標準の一部であるか、既知のMSVCバグであるか、コンパイラーの設定であるかどうか知りたいです。おおざっぱなグーグルは結果をもたらさなかった。

MSVC 1-1はNULLポインター定数と見なされます。これは、値0を持つすべての整数定数式がnullポインター定数であるC ++ 03の標準によって正しかったが、CWG問題903の C ++ 11の場合、ゼロ整数リテラルのみがnullポインター定数になるように変更されました。これは重大な変更であり、例でわかるように、また標準で文書化されているように、C ++ 14標準（ドラフトN4140）の[diff.cpp03.conv]を参照してください。

MSVCはこの変更を適合モードでのみ適用します。したがって、コードは/permissive-フラグでコンパイルされますが、変更はMSVC 2019でのみ実装されたと思います。こちらを参照してください。

GCCの場合、GCC 5のデフォルトはC ++ 98モードですが、GCC 6以降のデフォルトはC ++ 14モードです。そのため、動作の変更はGCCバージョンに依存しているようです。

f引数としてnullポインター定数を指定して呼び出す場合、nullポインター定数は任意のポインター型のnullポインター値に変換でき、この変換はint（または任意の整数型）の変換と同じランクを持つため、呼び出しはあいまいです。にdouble。

コンパイラーは[over.match]と [conv]、より具体的には[conv.fpint]と[conv.ptr] に従って正しく動作します。

標準の変換シーケンスは、[何とか何とか]ゼロまたは1つの[...]浮動小数点整数変換、ポインター変換、[...]です。

そして

整数型またはスコープ外の列挙型のprvalueは、浮動小数点型のprvalueに変換できます。可能であれば結果は正確です[何とか何とか]

そして

NULLポインター定数は、値がゼロまたは[...]の整数リテラルです。nullポインター定数はポインター型に変換できます。結果は、その型のnullポインター値です。

現在、オーバーロードの解決は、すべての候補関数の中で最も一致するものを選択することです（これは、楽しい機能として、呼び出しの場所でアクセスする必要さえありません！）。最適な一致は、正確なパラメーターを持つもの、または可能な限り変換が最も少ないものです。ゼロまたは1つの標準変換が発生する可能性があり（...すべてのパラメーターについて）、ゼロは1よりも「優れています」。

(1-1)は値を持つ整数リテラルです0。

あなたがゼロ整数リテラルに変換することができ、それぞれのいずれかdoubleまたはdouble*（もしくはnullptr_t）で正確に一つの変換。したがって、これらの関数が複数宣言されていると（例のように）、複数の候補が存在し、すべての候補が同等に良好である場合、最適な一致は存在しません。あいまいで、コンパイラは文句を言うのは正しいです。