彼の洞察に満ちた論文、
エラーと例外処理で、
@DaveAbrahamsは次のように述べています。
可能であれば、例外クラスを二重破壊の影響を受けないようにします。残念ながら、いくつかの一般的なコンパイラでは、例外オブジェクトが2回破棄されることがあります。それが無害になるように調整できる場合（たとえば、削除されたポインターをゼロにすることによって）、コードはより堅牢になります。
私はこの特定のガイドラインを理解することができません、誰かができますか：
@Tonyが言ったように、このガイドラインはコンパイラのバグに対する保護として意図されていました。このガイドラインは、例外のサポートがまだ少し不安定だった2001年頃にさかのぼります。それ以来、ほとんどのコンパイラがこのバグを修正したと思います。そのため、ガイドラインはもはやあまり関連性がないかもしれません。
FWIW、このガイドラインはCERTコーディング慣行から削除されました。このページの説明では、興味深い点が提起されています。オブジェクトを2回破壊することは、とにかくUBであるため、クラスでそれを処理するために何をしても、プログラムが完全に予測可能になることはありません。
ただし、コードをコンパイラー間（古いバージョンを含む）で移植できるようにしたい場合は、これらの小さな不具合をすべて考慮に入れる必要があります。たとえば、Boostはコンパイラのバグを回避するために多くの作業を行います。彼らは単に標準に準拠したコードを記述し、失敗の責任を実装に委ねることができますが、それは彼らのライブラリの採用を妨げるでしょう。
コードを書くときに同じ注意を払う必要があるかどうかは、要件によって異なります。基本的に、この質問に要約されます。数十のコンパイラをサポートすることは、意味する作業量に本当に値するのでしょうか。
@chrisaycockによる記事から引用するには：
「なぜ二度破壊するのか」？コンパイラのバグのため、それが理由です！これはエラーです。コンパイラはこれを行うべきではありません。しかし、彼らはそうします。私はSunのStudio8コンパイラを使用してこれに噛まれたプロジェクトに取り組みました。catch句でostringstreamオブジェクトを作成したところ、2回破棄されたことがわかりました。それを修正するために、私はそれを試す前に移動しました、そしてそれはうまくいきました。この種のバグはあまり発生しません。ほとんどの場合、catch句でオブジェクトを作成することは問題ありませんでしたが、注意する必要があります。
よろしく、
アンドリュー・マーロウ
標準には、1つのオブジェクトが2回破壊される可能性があるシナリオはありません。これが発生するインスタンスは、ユーザーに代わってバグであるか、オブジェクトが例外などのコンパイラーによって破壊された場合、コンパイラーのバグです。私はこれまで主要なコンパイラでこのようなバグについて聞いたことがなく、一般的にC++コードを書く人にとって問題になると信じる理由はありません。