3

以前のプログラムでは、次のコードを使用して、通常は代替案を考えずに、メモリ割り当ての失敗をチェックしました。

int* p_int = new int[10];
if(!p_int)
{
    // We failed, so exit
    return EXIT_FAILURE;
}

この方法については、こちらにも記載されています。

ここで構文のリファレンスを見つけました：

 p_int = (nothrow) new int[10];

nothrowプログラマーがnew への「引数」を含めない場合、チェックnullptrが無効になることを示唆していますか? これは正しいです？それともOS依存？

私が理解しているように、これに関連するオーバーヘッドのために、実際にブロックから回復できない限りnew、ブロックを配置してもほとんど意味がありません。try-catchこれも正しいですか？

4

2 に答える 2

3

失敗した場合はポインタが設定されないため、nullptr後のチェックは役に立ちません。newnewnullptr

int* p_int = new int[10];
if(!p_int)
{
    // error handling
}

むしろ、失敗した場合newは が発生throwするstd::bad_allocため、対処しようとする場合はtry、catch

try
{
    int* p_int = new int[10];
}
catch (const std::bad_alloc& e)
{
    std::cout << "Allocation failed: " << e.what();
    // deal with it
}
于 2015-08-23T16:23:05.893 に答える
2

はい、スローしないバージョンの new が使用されていない限り (そして、何か他のことをするためにオーバーロードされていない場合)、null を返すことはなく、代わりに例外がスローされます。また、ポインターを扱うときの null の遍在チェックに関しては、これは通常、見当違いです。せいぜい、デバッグ ビルドに限定する必要があります。ヌル ポインターは一般的に悪い (逆参照できない) ポインターの狭いサブクラスにすぎず、非デバッグ ビルドではめったに表示されないため、ヌルのチェックは単に CPU のウォームアップにすぎません。たとえば、ライブラリ関数は通常、入力の null をチェックしません。

于 2015-08-23T16:39:53.410 に答える