Déboguez-vous le code C ++ dans Vim? Comment?
La question s'adresse à vous tous, qui utilisez Vim pour développer des applications C++.
Il y a eu une période de ma vie que l'on peut qualifier de "je déteste Vim !!!" ... "Vim is Nice!"
Cependant, ayant grandi principalement sur les IDE de développement Microsoft, je me suis habitué à ces F5-F11 raccourcis lors du débogage du code, de la fenêtre de contrôle, de la pile d'appels et du code principal, le tout visible sans qu'il soit nécessaire de saisir une commande GDB.
Alors, voici la question:
tilisez-vous également Vim pour le débogage? Ou passez-vous à certains IDE à cette fin? Lequel?
Pour ceux qui utilisent Vim pour déboguer du code: existe-t-il des plugins pour définir des points d'arrêt dans l'éditeur, mettez en surbrillance la ligne en cours de débogage, de navigation automatique pas à pas, pas à pas?
S'il vous plaît, ne me dites pas que vous utilisez GDB en tant que ligne de commande, ne voyez qu'une seule ligne qui est déboguée, etc.
Contrairement aux autres réponses, il existe au moins trois options qui répondent exactement à vos besoins: clé , pyclewn et vimgdb .
Les trois projets sont liés. vimgdb est un correctif contre Vim et nécessite que Vim soit recompilé. clewn est un programme autonome qui communique avec Vim via l'interface de socket Netbeans. Cela nécessite que Vim soit construit avec le +netbeans option (c'est le cas dans les récentes distributions Linux, donc ça ne devrait pas être un problème).
Pour citer le site Web de Clewn:
Clewn implémente la prise en charge complète de gdb dans l'éditeur vim: points d'arrêt, variables de surveillance, exécution de la commande gdb, fenêtres d'assemblage, etc.
Je pense que vous devriez vraiment essayer.
La page d'accueil du site Internet pyclewn montre une comparaison entre les trois projets.
Il y a quelques mois, j'ai essayé pyclewn. C'était un peu difficile à mettre en place, mais ça a l'air bien et prometteur. Je viens de faire quelques tests et vous pouvez définir des signets, etc., les éléments habituels que vous pouvez attendre d'un débogueur graphique. J'ai fini par ne pas l'utiliser pour des raisons éventuelles, mais je suis désireux d'essayer à nouveau.
Vim est un éditeur sympa, mais pour le débogage, j’utilise un débogueur (comme GDB).
Mais vous n'êtes pas obligé d'utiliser GDB en mode texte; vous pouvez utiliser une interface graphique telle que KDbg , DDD ou Insight .
Il existe des moyens d’obtenir GDB dans Vim (mais vous obtenez alors un débogage à base de texte).
Vim a officiellement ajouté un débogueur intégré à la version 8.1, publié en mai 2018. Cette fonctionnalité était également présente dans certaines versions de la version 8.0, dès août 2017.
Les commandes vim suivantes chargent le plugin et lancent le débogueur.
:packadd termdebug
:Termdebug
Cette dernière commande prend un programme comme argument facultatif. Vous pouvez également charger un programme à partir de la fenêtre gdb avec la commande file.
Avec le plugin chargé, gdb peut être utilisé de manière interactive dans la fenêtre correspondante. Par exemple, des points d'arrêt peuvent être définis, le code peut être inséré et les variables peuvent être inspectées.
Des commandes Vim peuvent être émises pour interagir avec gdb. Certaines commandes pertinentes incluent :Step, :Over, :Finish, :Continue, :Stop, :Break, :Clear, et :Evaluate.
De plus, il y a des boutons cliquables en haut de la fenêtre de l'éditeur pour interagir avec gdb.
La fenêtre de l'éditeur est mise à jour pour refléter l'état du débogage. Les points d'arrêt sont indiqués par >> et la ligne en cours est mise en surbrillance.
La page d'aide intégrée inclut une documentation complète.
:help terminal-debug
J'ai récemment écrit un article de blog qui décrit une session d'exemple.
GDB edit commande
Ouvre un éditeur sur la ligne en cours en utilisant la commande:
$EDITOR +<current-line> <current-file>
La valeur par défaut editor est ex, mais vim comprend également le +<current-line> _ format.
Lorsque vous quittez l'éditeur, vous revenez dans gdb.
Cela vous permet de parcourir librement les sources et est particulièrement puissant si vous avez l'intégration ctags.
Il s'agit d'une intégration gdb à vim à sens unique pour un homme pauvre: la principale chose qui manque est la définition de points d'arrêt à partir de Vim.
edit et centre
edit ne centre pas Vim par défaut autour de la source, j'ai donc créé un script Python qui le fait: Comment ouvrir le fichier actuel à la version actuelle ligne dans un éditeur de texte de GDB?
Commande de point d'arrêt à l'aide du presse-papier
Cette commande vim copie un spécificateur de point d'arrêt de type:
b <file-path>:<line-number>
dans le presse-papier:
command! Xg :let @+ = 'b ' . expand('%:p') . ':' . line('.')
Ensuite, vous pouvez simplement coller cela dans gdb.
Il s’agit d’une intégration vim à gdb d’un pauvre pour faciliter l’établissement de points de rupture.
Tableau de bord GDB
https://github.com/cyrus-and/gdb-dashboard
Cela n’a rien à voir avec Vim, mais c’est une solution légère qui permet beaucoup de choses et qui pourrait convenir à d’autres Vimmers.
D'autres ont mentionné GDB TUI, mais je l'ai trouvé trop brisé et pas assez puissant pour être supportable.
J'ai donc plutôt opté pour Python solutions basées sur API, telles que GDB Dashboard.
J'ai décrit l'utilisation et la justification plus en détail à l'adresse suivante: vue fractionnée avec code
Voici une capture d'écran de ce que cela vous donne:
Voir aussi: https://vi.stackexchange.com/questions/2046/how-can-i-integrate-gdb-with-vim
Utiliser un débogueur au niveau de la source n’est qu’un des nombreux moyens de diagnostiquer un comportement de programme défectueux, et je me trouve rarement en train d’en lancer un - malgré le fait que cela est très facile à faire.
Donc pour moi, il n'y a tout simplement aucun avantage inhérent à utiliser un éditeur de texte qui se trouve être aussi un débogueur. Au lieu de cela, j'utilise l'éditeur de texte que je préfère - indépendamment de ce que le débogueur que je choisis d'utiliser. Pour le moment, j'utilise principalement gedit et kdbg à ces fins, mais ces choix évoluent indépendamment dans le temps.
Ayant récemment travaillé sur une application qui nécessitait un tas de choses sur la boîte où elle était en cours d'exécution (configuration de l'appliance), j'ai écrit du code dans vim, des scripts qui automatisaient la construction, la transmettant à un serveur. , qui contenait un script pour remarquer le fichier sentinelle poussé avec les fichiers binaires. Cela redémarrerait alors les services appropriés sur la boîte, et dans une autre fenêtre ssh, j’aurais un tail -f s'exécutant sur mon fichier journal.
Bref, je n'ai pas du tout utilisé de débogueur. Si quelque chose mourait de manière inattendue, je me contenterais d’augmenter les niveaux de journalisation, de le rétablir et de voir quelle était la dernière chose enregistrée avant sa mort, puis de l’analyser et de résoudre le problème.
Ce qui était bien, c’était que quand quelque chose avait des problèmes dans l’environnement client, je demandais simplement un journal au niveau du débogage et je pouvais identifier le problème sans même avoir besoin d’accéder à leur serveur.
... mais oui, il y avait des moments où il aurait été agréable d'avoir un débogueur.
Juste pour ajouter à ce qui précède:
IMO vim a tendance à être un éditeur très léger et le débogage tend à alourdir le poids. Il existe des moyens de le faire, c’est-à-dire en utilisant vim7.4 + avec
:terminal
et en exécutant l’un des débogueurs suivants en ligne de commande (curses). Quelques-uns sont utilisés par défaut pour des IDE que vous n'avez jamais connus. c'est-à-dire lldb = xcode.
- (c/c ++/Objective C) gdb (débogueur gnu) - https://www.gnu.org/software/gdb/
- (c/c ++/Objective C/python etc) remake - http://bashdb.sourceforge.net/remake/
- (Java) Oracle Java débogueur - https://docs.Oracle.com/javase/ 7/docs/technotes/tools/windows/jdb.html
- (c/c ++/Objective C) lldb - https://lldb.llvm.org/
évidemment, il y en a plus à base de cli; @tous n'hésitez pas à suggérer et à ajouter à la liste. Merci!