-2

Google で簡単に検索しましたが、この正確なトピックに関連するものを見つけることができませんでした。

C++ は、ラムダ、範囲ベースの for ループなどを含む、より現代的な言語に向けて動き続けているため、この質問がまだ出ていない場合でも、最終的に出てくる可能性があるようです。

これが良いこと以外の何物でもないとは思えず、C++/CLI、C#、Java などで有用であることが証明されているのと同じメリットを提供します。標準例外または RTTI を無効にするのと同じ方法で、オプションになり、コンパイラ設定で無効にされました。

また、提案された動作をシミュレートするために、SIGSEGV のシグナルハンドラーを作成し、そこから例外をスローすることが提案されていますが、推奨されていません。さて、これはちょっとしたハックであり、すべてのプラットフォームで動作することが保証されているわけではありませんが、同じ基本的な動作を約 10 行で (非標準的に) シミュレートできる場合、C++ で null 参照例外を実装するのは実際にはどれほど難しいでしょうか。コードの？

では、技術的またはその他の理由で、不正なポインター アクセスに対して例外をスローすることが将来的に標準の一部になることができないという理由はありますか?

4

3 に答える 3

5

編集: この質問に適切に答えるには、未来を正確に見ることができる必要があります。短期間なら簡単ですが、長くなるほど確実性は低くなります。ここでの私の回答は、近い将来を予見する試みと見なされるべきです。これが20〜30年で起こるかどうか、誰が知ることができますか?

一方では、技術的な観点から：

問題は、NULL 参照が不適切なポインターのシナリオの 1 つにすぎないことです。ランダムなガベージをポインター変数に挿入したり、解放後にメモリにアクセスしたりすると、メモリアクセスの不良を引き起こす何かが SIGSEGV を引き起こします。それが最初の問題です。

2 番目の問題は、すべてのハードウェアおよび/またはソフトウェアの組み合わせで、不正なポインター アクセスを検出できるわけではないこと、または不正なポインター アクセスの後に続行する方法がないことです。

if (ptr != NULL) ...EVERY ポインター逆参照の前に [コンパイラーがそれが有効なポインターであることを確認できない場合] を追加するだけでは、C++ が耐えられないほど遅くなります。

哲学的な観点から、RAII の使用: コード内で「生の」ポインターを使用しないでください。システムのメモリが不足している場合に例外newが発生します。std::bad_allocRAII スタイルの C++ でポインターを無効にする理由はまったくありません。RAII を使用していない場合は、使用する必要があります。

C++ は、まず高速で、次に洗練された言語になるように設計されました。

于 2013-08-18T23:39:47.563 に答える
0

不適切なポインター アクセスに対して例外をスローすることは、C++ の標準的な動作になりますか?

不正なポインタ アクセスを検出でき、言語によってそれに応じて例外をスローできます。

あなたが言うように、C++ にはラムダ、範囲ベースの for ループなどが含まれています。それは豊富な可能性を提供しますが、邪魔になることはなく、何かを強制することはありません。したがって、標準がそのような動作を強制するとは思いませんし、そうすべきではありません。

于 2013-08-19T00:25:45.063 に答える
0

いいえ、決して。例外の基本的なルールは、ステートメントによってスローされるというthrowことです。tryこれにより、ブロック内で例外をスローする可能性のあるコードをカプセル化できます。ほとんどすべてのステートメントが例外をスローできる場合、例外の安全性について推論するのははるかに難しくなります。

ポインターが制御不能な場合は、修正します。

于 2013-08-19T13:14:35.670 に答える