nullptr
私は、任意のポインター型に変換可能であることに加えて(ただし、整数型には変換できない)、独自の型も持っていることを学びましたstd::nullptr_t
。したがって、を受け入れるメソッドのオーバーロードを持つことが可能std::nullptr_t
です。
なぜそのような過負荷が必要なのですか?
複数のオーバーロードがポインタ型を受け入れる場合、引数std::nullptr_t
を受け入れるにはforのオーバーロードが必要です。nullptr
オーバーロードがないstd::nullptr_t
と、渡されたときにどのポインタオーバーロードを選択する必要があるかがあいまいになりますnullptr
。
例:
void f(int *intp)
{
// Passed an int pointer
}
void f(char *charp)
{
// Passed a char pointer
}
void f(std::nullptr_t nullp)
{
// Passed a null pointer
}
nullptr_t
タイプとの比較が、オブジェクトが有効かどうかを示すのに役立つ特殊なケースがいくつかあります。
たとえば、operator==
のとoperator!=
オーバーロードは、関数オブジェクトが空であるかどうかを判断するためのパラメータとしてstd::function
のみ使用できます。nullptr_t
詳細については、この質問を読むことができます。
また、他にどのようなタイプを提供しますか?それは、私たちが抱えていた問題を単に再導入するだけではありませんNULL
か?重要なのは、厄介な暗黙の変換を取り除くことですが、実際には古いプログラムの動作を変更することはできないので、ここにあります。
このタイプは、整数ゼロとヌルメモリの間の混乱を避けるために導入されました。そしていつものように、cppはあなたにタイプへのアクセスを与えます。一方、Javaは値へのアクセスのみを提供します。あなたがそれのためにどんな目的を見つけるかは本当に重要ではありません。私は通常、関数のオーバーロードのトークンとして使用します。
しかし、cppnullconstの実装にいくつか問題があります。
なぜ彼らは単にNULLまたはnullを続けなかったのですか?その定義はすでにその目的のために使用されていました。すでにnullptrを他の何かに使用していたコードはどうですか。
nullptrは長すぎることは言うまでもありません。入力するのが面倒で、ほとんどの場合見るのが醜い。変数をデフォルトで初期化するための6文字。
nullptrの導入により、ゼロは整数とnullポインター定数の両方ではなくなると思うでしょう。ただし、ゼロは依然としてその厄介なあいまいさを保持します。したがって、この新しいnullptr値の意味はわかりません。整数またはcharポインターを受け入れることができる関数を定義し、その関数呼び出しにゼロを渡すと、コンパイラーはそれが完全にあいまいであると文句を言います。そして、整数へのキャストが役立つとは思いません。
最後に、nullptr_tがstd名前空間の一部であり、単なるキーワードではないことを残念に思います。実際、関数でnullptr_tを使用してからしばらく経ってから、この事実を学んでいます。CodeBlocksに付属するMinGW32を使用すると、std名前空間でnullptr_tを使用する必要がなくなります。実際、MinGW32では、void*のインクリメントやその他の多くのことが可能です。
それは私を導きます:cppはあまりにも多くの宗派と混乱を持っています。あるコンパイラとのコードの互換性が、同じcppバージョンの別のコンパイラとの互換性ではないという点まで。あるコンパイラの静的ライブラリは、別のコンパイラでは機能しません。このようにしなければならない理由はありません。そして、これはcppを殺すのに役立つ1つの方法にすぎないと思います。