こんにちは、
私は通常、C プログラマーです。gdbやdbxなどのツールを使用して、UNIX環境でCプログラムを定期的にデバッグしています。私は C++ の大きなアプリケーションのデバッグをしたことがありません。それは、C でのデバッグ方法とは大きく異なります。理論的には、私は C++ が得意ですが、C++ プログラムをデバッグする機会はありませんでした。また、c++ でどのような技術的問題が発生し、開発者が問題を発見するためにデバッガーをオンにするかについてもわかりません。デバッガーを起動させる C++ で直面する一般的な問題は何ですか?
C++ プログラムのデバッグ中に ac プログラマーが直面する可能性のある課題は何ですか? Cに比べて難しくて複雑ですか？
基本的に同じです。
ブレークポイントを手動で設定するときは、名前空間とクラスの両方でメソッド名を完全に修飾する必要があることを覚えておいてください (結果として、行番号を使用してブレークポイントを定義する方が簡単な場合があります)。
デストラクタの呼び出しはソースでは見えないことを忘れないでください。ただし、ブロックの最後でデストラクタにステップ インすることはできます。
いくつかの小さな違い:
foo::bar::fum(args)gdb シェルなどで完全修飾記号を入力する場合、gdb がそれを認識して補完を計算するには、一重引用符で始める必要があります。
他の人が言ったように、ライブラリ テンプレートはデバッガーで内部を公開します。あなたはstd::vectorかなり簡単に突っ込むことができますが、突っ込むstd::mapことはあなたの時間を費やす賢明な方法ではないかもしれません.
C++ プログラムで一般的な積極的で大量のインライン展開により、コードの 1 行に終わりのない手順が含まれているように見える場合があります。ポインターへのすべてのアクセスがテンプレートの内部にインラインで展開されるため、shared_ptr のようなものは特に煩わしい場合があります。本当に慣れることはありません。
オーバーロードされたシンボル名が大量にある場合、readline 補完から必要なものを選択するのは不快な場合があります。(どの "foo" が欲しかったのですか? 全部ですか? この 2 つだけですか?)
GDB は C++ のデバッグにも使用できるため、C++ の仕組みを理解している場合 (およびオブジェクト指向の側面に起因する問題を理解している場合) は、それほど多くの問題は発生しないはずです (少なくとも、C プログラムをデバッグする場合とほとんど変わりません)。おもう...
GDB には、c++ のデバッグに関して困難な過去がありました。しばらくの間、コンストラクタ/デストラクタ内で効率的にブレークできませんでした。
また、stl コンテナーは、gdb で検査するのが非常に困難でした。 std::string痛みはありましたが、一般的に実行可能でした。 std::mapは非常に難しかったので、他に方法がない場合を除き、通常は print ステートメントを追加しました。
コンストラクタ/デストラクタの問題は、数年間修正されています。
stl サポートは gdb 7.0 で修正されました。
ブーストのライブラリにまだ問題がある可能性があります。私は時々、gdb に a の内容のロバを与えるのに苦労しましたshared_ptr。
したがって、独自の C++ のデバッグはそれほど難しくないと思います。問題になる可能性があるのは、サード パーティのクラスとテンプレート コードのデバッグです。
実際にはかなりの問題がありますが、使用しているデバッガー、そのバージョン管理などにも依存します:
デバッガーについて私が気に入っている点は、プライベート/保護されたクラス メンバーにアクセスするために get ルーチンを呼び出す必要がないことです。[obj-name].[var-name] だけで十分です。
アルパン
C++ オブジェクトは、分析が難しい場合があります。また、データは複数のクラス (複数のレイヤーにまたがる) にネストされることがあるため、「展開」するのに時間がかかる場合があります (このスレッドの他の人が既に述べているように)。使用される C++ 機能、プログラミング スタイル、および分析する問題の複雑さに大きく依存するため (実際には言語に依存しない)、一般的にそう言うのは困難です。
IMO: 非常に頻繁にデバッグする必要がある場合は、自分のプログラミング スタイルを再考する必要があります。通常、私にとっては、最後にエラー処理がすべてです。プログラムが予期しない動作をした場合、エラー ログには、どの段階で何が起こったかを再構築するのに十分な情報が示されているはずです。
これにより、プログラムがエンド ユーザーに出荷された後で問題をオフラインで「デバッグ」できるという利点も得られます。