問題タブ [exception-specification]

もしそうなら、どのように？

次のようなメンバーに例外仕様を提供する方法を知っています

そのため、methodスローのみSOMEException。SOMEClassthrow SOMEExceptionforのサブクラスを確実にしたいのですがpure_method、例外指定を追加することは可能でしょうか? このアプローチは実行可能ですか、それとも実行できない(できない)理由を見つけるために、例外と抽象メソッドについてもっと理解する必要がありますか?

私は経験豊富なアンマネージ C++ 開発者で、C++\CLI は初めてです。

マネージ C++ で例外指定が許可されないのはなぜですか?

リンク例

メソッドがスローする例外を指定するためのベストプラクティスは何ですか?

C++ コードを使用すると、呼び出し元に予期せず例外がスローされるという問題が発生しました。使用しているモジュールのすべての行を読んで、例外をスローするかどうか、またスローする場合はどのタイプの例外かを確認することは、常に可能または実用的ではありません。

この問題に対処するための確立されたイディオムまたは「ベスト プラクティス」はありますか?

私は次のことを考えました：

1. doxygen のドキュメントでは、例外をスローすると予想されるすべての関数とその型にコメントを追加できます。

   • プラス：シンプル。
   • マイナス: ユーザー エラーの対象となります。

2. try/catch(...)安全 のためにアプリ全体を使用できます。

   • 利点: キャッチされない例外はもうありません。
   • 短所: スローから離れた場所で例外がキャッチされます。何をすべきか、何が間違っていたのかを理解するのは難しいです。

3. 例外指定を使用する

   • プラス: これは、この問題に対処する言語認定の方法です。
   • マイナス: これを有効にするために必要な問題ライブラリのリファクタリング。コンパイル時に強制されないため、違反は実行時の問題に変わります。これは私が回避しようとしている問題です!

これらの方法の経験、または私が知らない追加の方法はありますか?

次のコードを検討してください。

コンパイルすると、派生クラス B は A に比べてスロー指定子が緩いことが示されます。これの重要性は何ですか? A::f() が int と double をスローし、B::f() が int のみをスローするように例外仕様を交換しようとすると、エラーは表示されません。

この機能が C++0x で非推奨になることはわかっていますが、まったくの初心者である私にとっては、この機能を使用することをお勧めします。誰かが私になぜ良い考えではないのか説明できますか?

最近、他の人が実装した dll を入手しました。アプリケーションで使用する必要があります。クラスのヘッダーファイルには、関数宣言があります

コンパイルすると、警告が表示されます。

関数が _declspec(nothrow) ではないことを示す場合を除き、C++ 例外仕様は無視されます

MSDN - ドキュメントを読みましたが、明確に理解できませんでした。また、表示されているという理由だけで警告を無効にしたくありません。無効にするのではなく、何が間違っているのかを知りたいです。

私は自分の関数を考えまし myfunc()た.dllからアクセスするとfunc1()、その例外仕様リストがありません。したがって、関数にも対応する例外仕様リストを用意してみました。

しかし、私はまだ警告を受けています。その警告とは何ですか?また、それを取り除く方法は? Windows XP で Qt 4.5 を使用しています。

C ++標準では、例外仕様を持つ仮想関数について次のように規定されています。

仮想関数に例外仕様がある場合、派生クラスのその仮想関数をオーバーライドする関数の定義を含むすべての宣言は、基本クラスの仮想関数（C +）の例外仕様によって許可される例外のみを許可するものとします。 +03§15.4/3）。

したがって、次の形式は正しくありません。

（1）このルールはデストラクタに適用されますか？つまり、次は整形式ですか？

（2）このルールは、暗黙的に宣言されたデストラクタにどのように適用されますか？つまり、次は整形式ですか？

一般的なケースでは、例外仕様を記述してはなりませんstd::exceptionが、デストラクタは仮想であり、空の例外仕様があるため、この質問には実際的な影響があります。

デストラクタから例外がスローされないようにすることをお勧めします。例を簡略化するために、デストラクタがすべての例外を許可する（つまり、例外指定がない）か、例外を許可しない（つまり、空の例外仕様があります）。

最近、同僚がC ++コードでの例外仕様の使用について私の意見を尋ねました。私は、Herb Sutter：A Pragmatic Look atExceptionSpecificationsによってこの記事をまとめることができました。ハーブサッターのほとんどの記事と同様に、この記事は教育的な読み物ですが、簡単な答えは「そうしないでください」です。

要約すると、彼は「実装前の夜だった」というタイトルの詩に言及しています。この詩では、標準委員会は、事実上、最後の最後に機能を追加するというユーザーの要求に屈しますが、それが何をしているのかを発見するだけです。求められた、それは本当に彼らが望んでいたことをしません。そして、はい、例外仕様はその法案に適合します。彼が言うように、「この機能は当時は良いアイデアのようでした。それはまさに一部の人が求めていたものです。」それでも不十分な場合は、「エクスポート」にアクセスすると、同様の悲しい結果が得られます。

だから問題はこれです：あなたが涙を経験したくないのであれば、C ++のどの「機能」が壊れていることが判明し、使用すべきではありません。これは主観的な罵倒の餌食になるかもしれませんが、測定可能な問題を引き起こすためだけに機能が展開された特定の経験を引用してくれることを願っています。さらに良いのは、Sutter（または標準に深く関わっている人）のような先導灯による記事の引用で、機能について人々に警告することです。

次のような例外クラスがあります。

-Wall -std = c++0xを使用してGCC4.4でコンパイルする場合

エラー：'virtual const char * InvalidPathException :: what（）const'のスロー指定子が緩い

エラー：オーバーライド'virtual const char * std :: exception :: what（）const throw（）'

確かに例外指定子を持っているstd::exceptionのメソッドをオーバーライドしているので、まったく正しいです。ただし、多くの場合通知されるため、例外指定子を使用しないでください。そして私が理解しているように、それらはC ++ 11で非推奨になっていますが、-std = c++0xを使用したGCCではまだ明らかにされていません。what()throw()

ですから、今のところ最善のアプローチに興味があります。私が開発しているコードでは、パフォーマンスを気にしているので、よく言及されるオーバーヘッドについて心配していますthrow()が、実際には、このオーバーヘッドはそれほど深刻ですか？私what()は、実際に呼び出されたときにのみ問題が発生するだろうと思っていますか？それは、そのような例外がスローされた後だけです（同様に、すべてにthrow()指定子があるstd :: exceptionから継承された他のメソッドの場合）？

あるいは、GCCによって与えられたこのエラーを回避する方法はありますか？