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é.
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:
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. 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. 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. 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.