Débogage des meilleures pratiques pour C ++ STL / Boost avec gdb

Déboguer avec gdb, tout code c ++ utilisant STL / boost est toujours un cauchemar. Quiconque a utilisé gdb avec STL le sait. Par exemple, consultez des exemples de exécutions de certaines sessions de débogage dans le code ici .

J’essaie de réduire la douleur en recueillant des conseils. Pouvez-vous commenter les conseils que j’ai collectés ci-dessous (en particulier ceux que vous avez utilisés et les modifications que vous recommanderiez) – J’ai listé les astuces par ordre décroissant de technicité.

  • Est-ce que quelqu’un utilise “les utilitaires STD de Stanford GDB” et les “utils UCD GDB” ? Existe-t-il de tels outils pour renforcer les structures de données? Les utils ci-dessus ne semblent pas être utilisables de manière récursive, par exemple pour imprimer le vecteur d’un boost :: shared_ptr de manière lisible au sein d’une même commande.
  • Ecrivez votre fichier .gdbinit. Inclure, par exemple, les esthétiseurs liés au C ++, répertoriés au bas des utilitaires UCD GDB.
  • Utilisez la bibliothèque check / debug STL / Boost, telle que STLport.
  • Utiliser la journalisation (par exemple comme décrit ici )

Mise à jour : GDB a une nouvelle twig C ++ .

Peut-être pas le genre de “conseil” que vous cherchiez, mais je dois dire que mon expérience après quelques années de passage de C ++ & STL à C ++ & boost & STL est que je passe beaucoup moins de temps dans GDB que dans habitué. Je mets cela sur un certain nombre de points:

  • booster les pointeurs intelligents (en particulier “pointeur partagé” et les conteneurs de pointeurs lorsque les performances sont nécessaires). Je ne me souviens plus de la dernière fois que j’ai dû écrire une suppression explicite (delete est le “goto” de C ++ IMHO). Il se passe beaucoup de temps GDB traquer les pointeurs non valides et les fuites.
  • boost est plein de code éprouvé pour des choses que vous hackeriez probablement ensemble avec une version inférieure. Par exemple, boost::bimap est idéal pour le schéma commun de la logique de mise en cache LRU. Il y a un autre tas de temps GDB.
  • Adopter le désengagement. Les macros AUTO de boost::test signifient que la configuration des cas de test est plus compliquée que CppUnit . Cela attrape beaucoup de choses bien avant qu’il soit intégré à tout ce que vous devez attacher un débogueur.
  • Dans ce contexte, des outils tels que boost::bind facilitent la conception-test. Par exemple, les algorithmes peuvent être plus génériques et moins liés aux types sur lesquels ils opèrent. Cela facilite les twigments dans les shims / proxies / objects de test, etc. (et le fait que l’exposition au style de modèle de boost vous encouragera à «oser modéliser» des choses que vous n’auriez jamais considérées auparavant, offrant des avantages de test similaires).
  • boost::array . Performances “C array”, avec vérification de la scope dans les versions de débogage.
  • boost est plein de code génial que vous ne pouvez pas vous empêcher d’apprendre

Vous pourriez regarder:

Inspection du contenu du conteneur standard (std :: map) avec gdb

Je pense que l’option la plus simple et la plus simple consiste à utiliser la journalisation (enfin, j’utilise des impressions de débogage, mais je pense que ce n’est pas un point). Le plus grand avantage est que vous pouvez inspecter tout type de données, plusieurs fois par exécution de programme, puis le rechercher avec un éditeur de texte pour rechercher des données intéressantes. Notez que c’est très rapide. L’inconvénient est évident, vous devez présélectionner les données que vous souhaitez enregistrer et les lieux où se connecter. Cependant, ce n’est pas un problème grave, car vous savez généralement où se trouvent les mauvaises choses dans le code (et si ce n’est pas le cas, vous ajoutez simplement des vérifications de cohérence ici et là, vous le saurez).

Les bibliothèques vérifiées / de débogage sont bonnes, mais elles sont meilleures en tant qu’outils de test (par exemple, exécutez-les et voyez si je fais quelque chose de mal), et ne sont pas aussi efficaces pour déboguer un problème spécifique. Ils ne peuvent pas détecter une faille dans le code utilisateur.

Sinon, j’utilise la GDB ordinaire. Ce n’est pas si grave que cela puisse paraître, bien que cela puisse être le cas si vous êtes effrayé par ” print x ” en imprimant un écran de déchets. Mais, si vous avez des informations de débogage, des choses comme l’impression d’un membre d’un travail std::vector et si quelque chose échoue, vous pouvez toujours inspecter la mémoire brute par la commande x . Mais si je sais ce que je cherche, j’utilise l’option 1 – logging.

Notez que les structures “difficiles à inspecter” ne sont pas seulement STL / Boost, mais également d’autres bibliothèques, telles que Qt / KDE.