問題タブ [nullptr]

重複の可能性：
nullptrとは正確には何ですか？

最初はキーワードだと思いました。nullptr私の現在のgccは別の色合いで強調表示されません。それを確認するために、私は次のように書いた：

だから私はエラーからいくつかの手がかりを得ました：

エラー：タイプ'std ::nullptr_t'の右辺値からのタイプ'void*＆'の非定数参照の無効な初期化</ p>

がオブジェクトの場合nullptr、それは本当に単純なものと同等のポインタ0ですか？言い換えれば、私が次のように書いたとしましょう。

上記のステートメントは私のコードの何も変更しませんか？また、タイプ自体の他のユースケースを知ることも興味深いでしょうstd::nullptr_t。

C++11 の実装は として定義NULLされnullptrますか?

これは、新しい C++ 標準によって規定されますか?

Visual Studio 2010 で C++ を使用しています。 を に変換中NULLですnullptr。私のコードではこれで問題ありません。ただし、次のような WINAPI を呼び出すと:

通常、私はこれを次のように呼び出します：

このような通話でnullptr使用したはずの場所を安全に使用できますか?NULL

つまり、私はこれを行うことができます:

また、MFC api と同じ:

交換できますか

できると思いますが、落とし穴がないことを確認したいだけです。

アップデート

だから私は行って、すべての NULL を nullptr に置き換えました。ほとんどどこでも機能するようですが、次の行で以下のエラーが発生しています。

8>c:\something\something.cpp(118): エラー C2664: 'CMFCPropertyGridProperty::CMFCPropertyGridProperty(const CString &,const COleVariant &,LPCTSTR,DWORD_PTR,LPCTSTR,LPCTSTR,LPCTSTR)': 'nullptr からパラメーター 4 を変換できません' to 'DWORD_PTR' 8> ネイティブ nullptr は bool に、または reinterpret_cast を使用して整数型にのみ変換できます

(CMFCPropertyGridProperty は Microsoft MFC クラスであることに注意してください) では、それはどういう意味ですか?

多かれ少なかれ、タイトルが示唆するもの。私はまだ C++0xを使用していませんが、それが起こったときに備えたいと思います。また、その機能の一部を使用するために書き直さなければならないコードの量を減らしたいと考えています。そうすれば、後方互換性と前方互換性を一度に取得できます。

私が見つけた最も興味深いものの 1 つは で、nullptr最近頻繁に使用しています。

「公式の回避策」とMeyer の提案を確認した後、これを自分の C++ プログラムと将来の C++0x プログラムの両方で使用することにしました。2 番目の部分は単純です。キーワードであるため、nullptr単純にサポートされます。しかし、最初の部分は私に不快感を与えています。

Meyers の提案は次のように機能します。

std::nullptr_tその提案の問題点は、C++0x で必要とされる型を宣言することです。つまり、回避策を「ネイティブに感じる」には、std::名前空間を再度開いて型を追加する必要があります。私は、C ++プログラムで行うのは違法であることを理解しています（明らかに警告を発して眉をひそめているように見える特殊化を追加するのとは異なります）。

C++ プログラムでnullptr快適かつ合法的な方法で使用したい。私が考えていたオプションの 1 つは、別の名前空間で型を宣言し、それを次のように使用することでしたusing。

これはそれを機能させる正しい方法でしょうか？ディレクティブを強制usingし、特定の順序の#includeディレクティブも強制します。nullptr_tC++0x より前のコードでは、名前空間を持つ型を (たとえば、関数の引数の型として)要求しないと期待するのは正しいでしょうか? このようにすると、実際に「ネイティブ感」が得られるでしょうか？

補足として、互換性とコーディングを改善するために、いくつかの気の利いた C++0x のものを C++ にバックポートしようとすることは、歓迎されることですか、それとも嫌われることですか? それまでの間、私はこのソリューションと、私が取り組んでいる他のソリューションを、リリースされるソフトウェアに統合しました。

とても簡単な質問があります...

私は C で書かれた SDL API を使用しています。私は C++ を使用しています。私のコンパイラはキーワード nullptr をサポートしており、それについて調べています。NULL マクロを使用するよりも使用した方がよいようです。

SDL_SetVideoMode を呼び出すと、失敗すると NULL が返されると想定するので、次のようにします。

これは、サーフェス テストでの最適化が成功したかどうかを正確に確認しますか?

私は多くの最上位のヘッダーファイルで以下のマクロを見てきました：

コード全体で、NULLは0同じ意味で使用されます。に変更すると。

それは悪い副作用を引き起こしますか？次の使用法は不整形になるので、私は唯一の（良い）副作用を考えることができます。

nullptr_t にデフォルトのコンストラクターがあるかどうかは、C++11 標準からわかりません。言い換えれば、次は有効ですか?:

GCC と VC++ では上記のコードを使用できますが、clang では使用できません。標準にはデフォルトのコンストラクターがないことを指定するものは何も見つかりません。古いコンパイラのサポートのために nullptr の基本的なフォールバック実装を書いていて、デフォルトのコンストラクタを与える必要があるかどうかを知る必要があるため、これは私にとって重要です。

重複の可能性:
nullptr を C++-pre-C++0x プログラムに「バックポート」する

nullptrC++03 と C++11 の両方をサポートするための定義方法は?

以下のコードは、C++11 コンパイラの nullptr の意味を変更せずに、C++03 と C++11 の両方のコンパイルでコンパイルされますか?

私は、gcc 4.5.3 を使用している 2 人のエンド ユーザーと、gcc 4.6.3 に移動したばかりの 2 人のエンド ユーザーがいるライブラリに取り組んでいます。このライブラリは、新しい C++11 スマート ポインター (特に unique_ptr) を使用し、gcc 4.5.3 で正常にコンパイルされます。ただし、これらの 2 つのバージョンの間で、gcc は nullptr のサポートを開始したため、unique_ptr の API が変更され、標準により厳密に一致するようになりました。そうすることで、次のコードは問題ありませんでした。

nullptr の有無にかかわらず動作するように、上記の if ステートメントを変更するクリーンな (つまり、次の文の) 方法はありますか? 可能であれば、構成チェックを避けてから、次のようなマクロ（これでうまくいくと思います）を避けたいと思います

または、これが私が探している動作を取得する唯一の方法ですか?

OK、最初に関連する可能性のあるいくつかのこと:

Clang 3.1 コンパイラを C++11 モードで使用し、標準ライブラリを libc++ に設定しています。

私は C++11 に慣れようとしていますが、そうしているうちに奇妙な動作に出くわしました。それはClangまたはlibc ++の癖かもしれませんが、私はC ++標準語を話すことができず、C ++ 11をサポートする他のコンパイラにアクセスできないため、実際に確認することはできません。インターネットとスタックオーバーフローを検索しました関連するものを見つけることなく、私の能力を最大限に発揮します...だからここに行きます：

shared_ptr / unique_ptr を使用して単純なリソースの RAII を実装する場合、削除時の null ポインターに関してそれらの動作が異なるようです。通常、ヌル ポインターを削除する必要はないことは認識していますが、少なくとも 2 つの STL スマート ポインター間で動作が一致することを期待していました。

特定のケースでは、次のコードを検討してください。

これから、次のいずれかの出力が期待されます。

a) ポインターがヌルであっても、両方のデリータが呼び出された場合:

b) ポインターが null であるため、どちらのデリータも呼び出されない場合:

しかし、私はこれらのケースのどちらも観察しません。代わりに、私は次のことを観察します。

これは、一方のデリータが呼び出され、もう一方が呼び出されていないことを意味します。さらに調べてみると、shared_ptr のデリータは null 値を保持しているかどうかに関係なく呼び出されますが、unique_ptr のデリータは null 値を保持していない場合にのみ呼び出されることがわかりました。

私の質問: これは実際に標準で指定されている正しい動作ですか? もしそうなら、なぜこのように 2 つの STL タイプ間で指定された動作が異なるのでしょうか? そうでない場合、これは libc++ に報告すべきバグですか?