46

gdbを使用してデバッグする場合、STL/boostを使用するc++コードは依然として悪夢です。STLでgdbを使用したことがある人なら誰でもこれを知っています。たとえば、ここのコードでいくつかのデバッグセッションのサンプル実行を参照してください。

ヒントを集めて痛みを和らげようとしています。以下に収集したヒントについてコメントしていただけますか（特に、使用しているヒントと、それらに推奨する変更）-ヒントは技術の降順でリストされています。

  • 「StanfordGDBSTLutils」と「UCFGDButils 」を使用している人はいますか？ブーストデータ構造のためのそのようなユーティリティはありますか？上記のutilsは、たとえば、1つのコマンド内で読みやすい方法でboost :: shared_ptrのベクトルを出力する場合など、再帰的に使用できるようには見えません。
  • .gdbinitファイルを作成します。たとえば、UCFGDButilsの下部にリストされているC++関連のビューティファイアを含めます。
  • STLportなどのチェック済み/デバッグSTL/Boostライブラリを使用します。
  • ロギングを使用します（たとえば、ここで説明されているように）

更新：GDBには新しいC++ブランチがあります。

4

3 に答える 3

15

あなたが探していたような「ヒント」ではないかもしれませんが、C++ & STL から C++ & boost & STL に移行して数年後の私の経験では、私が GDB に費やす時間は私よりもはるかに少ないと言わざるを得ません。慣れている。私はこれをいくつかのことに分類します：

  • スマート ポインター (特に「共有ポインター」、およびパフォーマンスが必要な場合のポインター コンテナー) を強化します。最後に明示的な削除を書かなければならなかったのはいつだったか思い出せません (削除は C++ IMHO の「goto」です)。GDB では、無効なポインタやリークしているポインタを追跡するのに多くの時間がかかります。
  • ブーストには、他の方法の劣ったバージョンを一緒にハックする可能性のある、実証済みのコードがたくさんあります。たとえばboost::bimap、LRU キャッシング ロジックの一般的なパターンに最適です。GDB時間の別のヒープがあります。
  • 単体テストの採用。 boost::testの AUTO マクロは、テスト ケースを設定するのが絶対に面倒であることを意味します ( CppUnit よりも簡単です)。これは、デバッガーを接続する必要があるものに組み込まれるずっと前に、多くのものをキャッチします。
  • それに関連して、次のようなツールを使用すると、boost::bindテスト用の設計が容易になります。たとえば、アルゴリズムはより一般的になり、操作対象の型との結びつきが少なくなります。これにより、それらをテスト shim/proxy/mock オブジェクトなどにプラグインすることが容易になります (さらに、boost のテンプレートの魅力に触れることで、これまで考えたこともなかったようなことを「あえてテンプレート化」することが促進され、同様のテストの利点が得られます)。
  • boost::array. デバッグ ビルドでの範囲チェックによる「C 配列」のパフォーマンス。
  • boost には、学ばずにはいられないすばらしいコードがたくさんあります
于 2009-01-12T14:39:17.160 に答える
5

あなたは見るかもしれません：

gdbを使用した標準コンテナ（std :: map）の内容の検査

于 2009-01-11T19:16:06.197 に答える