これでうまくいきましたが、かなり醜いですし、たくさんのことをする必要があるときはあまり友好的ではありません.
(gdb) break diff_match_patch<std::__1::basic_string<wchar_t, std::__1::cha
r_traits<wchar_t>, std::__1::allocator<wchar_t> >, diff_match_patch_traits
<wchar_t> >::diff_linesToCharsMunge
Breakpoint 4 at 0x100021a1c: file diff_match_patch.h, line 658.
(gdb)
行番号からブレークポイントを設定できます。これは、私がほとんどの場合に頼ることになる可能性が高いです。
関数の名前でブレークポイントを設定するには、それがたまたまテンプレートの山の下にある場合 (STL コンテナーを継承するクラスなど... 不平不満)、この試練を経て、その不敬な署名を取得する必要があります。関数を中断するため。
これを達成する方法は次のとおりです。私のOS X 10.8.4ではbreak、gdbプロンプトで入力し、プレフィックス（この場合はクラスの名前であるdiff_match_patch）から始めてから、タブ補完。この時点で、関数のシグネチャを分離するために tmux の検索モードを使用します ( diff_linesToCharsMunge)。そこに貼り付けたものが、関数のシグネチャの最初の部分であることがわかります。これは、gdb にブレークポイントを喜んで設定させるのに十分です。
これをもう少し改善したいのですが、どうすればよいかわかりません。コマンドラインにとどまることで、物事をクリーンで堅牢に保ちたいと思っています。
素敵な (そして使いやすい) GUI インターフェースが必要な場合は、このコードを XCode プロジェクトにセットアップしてそこから移動するのが良い方法だと思います。
しかし、よりコアな UNIX スタイルのアプローチを採用したい場合、どのような選択肢があるでしょうか?
gdb は確かにしっかりしています (そして、clang でコンパイルされた C++11 コードとシームレスに動作するように見えてうれしいです)、たとえばipython. ipython には本格的な構文強調表示があります。clang コンパイラは、きれいに色付けされた非常にわかりやすい (gcc少なくとも参照) エラーと警告を生成します。かわいらしいスクイーグで、おかしな表情の部分を見せてくれます。gdb比較すると、歯が長く感じられます。
だから私はこの仕事を少しでも楽にしようとしているだけです... 苦痛です。改善する領域は...
- 関数シグネチャの途中からタブ補完検索を行うため、関数の合理的な人間が知っている名前を入力した後にタブで移動できます
- 実際には #1 が要約していますが、他のことを行う実行可能な回避策 (行番号はそれらの 1 つだと思います... ため息) は大歓迎です。ご存知のように、
clangプロジェクトに壮大な機能が豊富なgdbフロントエンドがあることを願っています。