VimでC ++コードをデバッグしますか？どうやって？
問題は、Vimを使用してC++アプリケーションを開発するすべての皆さんです。
私の人生には、「私はVimが嫌いです!!!」と表現できる期間がありました。「Vim is Nice！」
しかし、主にマイクロソフトの開発IDEで育ったので、それらに慣れてきました。 F5-F11 コード、ウォッチウィンドウ、コールスタック、メインコードのデバッグ時のショートカット-すべてGDBコマンドを入力する必要なく表示されます。
だから、ここに質問があります：
デバッグにもVimを使用しますか？または、この目的のためにIDEに切り替えますか？どれですか？
Vimを使用してコードをデバッグする場合：エディターにブレークポイントを設定するプラグインがあり、現在デバッグしている行を強調表示し、ステップ中の自動ナビゲーション、ステップイン、ステップアウトしますか？
コマンドラインとしてGDBを使用していることを教えてはいけません。デバッグされている1行のみを参照してください。
他の答えとは対照的に、必要なことだけを行う少なくとも3つのオプションがあります： clewn 、 pyclewn 、および vimgdb 。
3つのプロジェクトはすべて関連しています。 vimgdbはVimに対するパッチであり、Vimの再コンパイルが必要です。 clewnは、Netbeansソケットインターフェイスを介してVimと通信するスタンドアロンプログラムです。これには、Vimを+netbeansオプションでビルドする必要があります（これは最近のLinuxディストリビューションに当てはまるため、問題ではないはずです）。
ClewnのWebサイトから引用するには：
Clewnは、vimエディターで完全なgdbサポートを実装します：ブレークポイント、監視変数、gdbコマンドの完了、アセンブリウィンドウなど。
絶対にやってみるべきだと思います。
Pyclewn Webサイトのホームページは、3つのプロジェクトの比較を示しています。
数ヶ月前、pyclewnを試しました。設定するのは少し難しいものでしたが、見栄えはよく、有望です。いくつかのテストを行っただけで、ブックマークなどを設定できます。これは、通常のグラフィカルデバッガーに期待されるものです。偶発的な理由でそれを使用しないことになりましたが、もう一度試してみたいと思います。
Vimは、2018年5月にリリースされたバージョン8.1に組み込みのデバッガーを公式に追加しました。この機能は、2017年8月にはバージョン8.0リリースの一部にも存在していました。
次のvimコマンドはプラグインをロードし、デバッガーを開始します。
:packadd termdebug
:Termdebug
後者のコマンドは、オプションの引数としてプログラムを使用します。あるいは、gdbコマンドを使用して、fileウィンドウからプログラムをロードできます。
プラグインをロードすると、対応するウィンドウでgdbをインタラクティブに使用できます。たとえば、ブレークポイントを設定したり、コードをステップ実行したり、変数を検査したりできます。
gdbと対話するためにVimコマンドを発行できます。関連するコマンドには、:Step、:Over、:Finish、:Continue、:Stop、:Break、:Clear、および:Evaluate。
さらに、gdbとやり取りするためのエディターウィンドウの上部にクリック可能なボタンがあります。
エディタウィンドウが更新され、デバッグの状態が反映されます。ブレークポイントは>>で示され、現在の行が強調表示されます。
組み込みのヘルプページには、詳細なドキュメントが含まれています。
:help terminal-debug
私は最近、セッションの例を紹介するブログ投稿を書きました。
GDB editコマンド
次のコマンドを使用して、現在の行でエディターを開きます。
$EDITOR +<current-line> <current-file>
デフォルトのeditorはexですが、vimは+<current-line>形式も理解します。
エディターを終了すると、gdbに戻ります。
これにより、ソースを自由に閲覧でき、ctags統合があれば特に強力です。
これは貧弱な人が組み込みのgdbからvimへの統合です。主な不足していることは、Vimからブレークポイントを設定することです。
editおよびcenter
editはデフォルトでソースの周りにVimを配置しないため、それを行うPythonスクリプトを作成しました。 テキストの現在の行で現在のファイルを開く方法GDBのエディター？
クリップボードヘルパーへのブレークポイントコマンド
このvimコマンドは、タイプのブレークポイント指定子をコピーします。
b <file-path>:<line-number>
クリップボードへ：
command! Xg :let @+ = 'b ' . expand('%:p') . ':' . line('.')
次に、それをgdbに貼り付けるだけです。
これは、ブレークポイントの設定を容易にするためのgdb統合に対する貧弱な人のvimです。
GDBダッシュボード
https://github.com/cyrus-and/gdb-dashboard
これはVimとは何の関係もありませんが、多くのことを実現し、他のVimmerに適合するかもしれない軽量のソリューションです。
他の人はGDB TUIに言及しましたが、私はそれがあまりにも壊れており、耐えられるほど強力ではないことに気付きました。
そこで、代わりにGDBダッシュボードなどのPython APIベースのソリューションに移動しました。
使用および理論的根拠について詳しく説明しました： gdb split view with code
以下にスクリーンショットを示します：
参照： https://vi.stackexchange.com/questions/2046/how-can-i-integrate-gdb-with-vim
ソースレベルのデバッガーを使用することは、障害のあるプログラムの動作を診断する多くの方法の1つに過ぎず、非常に簡単であるにもかかわらず、起動することはめったにありません。
したがって、私にとっては、たまたまデバッガーでもあるテキストエディターを使用することに固有の利点はありませんです。代わりに、使用するデバッガーとは無関係に、好みのテキストエディターを使用します。現時点では、これらの目的で主にgeditおよびkdbgを使用していますが、これらの選択肢は時間の経過とともに独立して進化します。
実行中のボックス（アプライアンスのセットアップ）に大量のものを配置する必要があるアプリケーションで最近作業を行ったばかりで、vimでコードを記述し、ビルドを自動化してサーバーにプッシュするスクリプトを作成しました、そこには、バイナリと一緒にプッシュされたセンチネルファイルに気付くスクリプトがありました。これにより、ボックスの適切なサービスが再起動され、別のsshウィンドウでログファイルでtail -fが実行されていました。
要するに、私はデバッガーをまったく使用しませんでした。予期せず何かが死んでしまった場合、ログレベルを上げてやり直し、死ぬ前に最後に記録されたものを確認し、それを分析して問題を修正します。
良い点は、顧客環境で何か問題が発生したときに、デバッグレベルのログを要求するだけで、サーバーへのアクセスを必要とせずに問題を特定できることでした。
...しかし、はい、デバッガーを持っていたことが良かった場合がありました。
上記に追加するだけです：
IMO vimは非常に軽量なエディターである傾向があり、デバッグは重みを増す傾向があります。それを行う方法があります。つまり、vim7.4 +を
:terminal
次のコマンドライン（curses）デバッガーのいずれかを実行します。知らなかったIDEにはデフォルトでいくつかが使用されます。すなわち、lldb = xcode。
- （c/c ++/Objective C）gdb（gnuデバッガー）- https://www.gnu.org/software/gdb/
- （c/c ++/Objective C/pythonなど）remake- http://bashdb.sourceforge.net/remake/
- （Java）Oracle Java debugger- https://docs.Oracle.com/javase/7/docs /technotes/tools/windows/jdb.html
- （c/c ++/Objective C）lldb- https://lldb.llvm.org/
明らかに、CLIベースのものがもっとあります。 @allが提案し、リストに追加してください。ありがとう！