Debugowanie najlepszych praktyk dla C++ STL / Boost z gdb

Debugowanie za pomocą gdb, każdy kod c++, który używa STL / boost jest nadal koszmarem. Wie o tym każdy, kto używał gdb z STL. Na przykład, zobacz przykładowe przebiegi niektórych sesji debugowania w kodzie tutaj .

Staram się zmniejszyć ból, zbierając napiwki. Czy możesz skomentować wskazówki, które zebrałem poniżej (szczególnie te, których używasz i wszelkie zmiany, które poleciłbyś na nich) - wymieniłem wskazówki malejące w kolejności technicznej.

  • czy ktoś używa "Stanford GDB STL utils" i "UCF GDB utils" ? Czy są jakieś takie utile dla struktur danych boost? Powyższe utile nie wydają się być użyteczne rekurencyjnie, na przykład do wydrukowania wektora boost::shared_ptr w czytelny sposób w ramach jednego polecenia.
  • Napisz swoje .plik gdbinit. Obejmują na przykład upiększacze związane z C++, Wymienione na dole utils UCF GDB.
  • użyj sprawdzonej / debugowanej biblioteki STL / Boost, takiej jak STLport.
  • Użyj logowania (na przykład zgodnie z opisem tutaj)

Aktualizacja : GDB ma nową gałąź C++ .

Author: phaedrus, 2009-01-11
Source

3 answers

Może nie taki rodzaj "napiwku", którego szukałeś, ale muszę powiedzieć, że moje doświadczenie po kilku latach przechodzenia z C++ & STL do C++ & boost & STL jest takie, że spędzam teraz dużo mniej czasu w GDB niż kiedyś. Odkładam to na kilka rzeczy:

  • zwiększ Inteligentne Wskaźniki(szczególnie "shared pointer" i kontenery wskaźników, gdy wymagana jest wydajność). Nie pamiętam, kiedy ostatni raz musiałem napisać wyraźne delete (delete to "goto" C++ IMHO). Dużo czasu spędza na śledzeniu nieprawidłowych i nieszczelnych wskaźników.
  • boost jest pełen sprawdzonego kodu do rzeczy, które prawdopodobnie zhakowałbyś razem gorszą wersję w przeciwnym razie. e. g boost::bimap jest świetny dla wspólnego wzorca logiki buforowania LRU. Idzie kolejna kupa czasu GDB.
  • Adopting unittesting. Automatyczne makra boost::test oznaczają, że konfigurowanie przypadków testowych (jest prostsze niż CppUnit). To łapie wiele rzeczy na długo zanim zostanie wbudowany w cokolwiek musisz dołączyć debugger.
  • powiązane z tym narzędzia takie jak boost::bind ułatwiają projektowanie do testów. na przykład algorytmy mogą być bardziej ogólne i mniej powiązane z typami, na których działają; to sprawia, że podłączanie ich do testowych podkładek / proxy / mock obiektów itp. jest łatwiejsze (to i fakt, że ekspozycja na szablon Boosta zachęci cię do "odważenia się na szablon" rzeczy, których nigdy wcześniej nie brałeś pod uwagę, przynosząc podobne korzyści testowe).
  • boost::array. "Tablica C" wydajność, z sprawdzaniem zakresu w kompilacjach debugowania.
  • boost jest pełen wspaniałego kodu, z którego nie możesz się nie nauczyć
 15
Author: timday,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-04-17 07:30:02
 5
Author: Mr.Ree,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:17:14

Myślę, że najprostszą i najskuteczniejszą opcją jest użycie logowania(cóż, faktycznie używam wydruków debugujących, ale myślę, że nie o to chodzi). Największą zaletą jest to, że można sprawdzać każdy typ danych, wiele razy na wykonanie programu, a następnie przeszukiwać je za pomocą edytora tekstu, aby wyszukać interesujące dane. Zauważ, że jest to bardzo szybkie. Wada jest oczywista, musisz wstępnie wybrać dane, które chcesz zalogować i miejsca, w których chcesz się zalogować. Jednak nie jest to tak poważny problem, ponieważ zwykle wiesz gdzie w kodzie dzieją się złe rzeczy (a jeśli nie, po prostu dodajesz sprawdzanie rozsądku tu i tam, a potem będziesz wiedział).

Biblioteki Checked / debug są dobre, ale są lepsze jako narzędzie testujące (np. uruchom go i sprawdź, czy robię coś złego), a nie tak dobry w debugowaniu konkretnego problemu. Nie mogą wykryć wady w kodzie użytkownika.

W przeciwnym razie używam zwykłego GDB. Nie jest tak źle, jak to brzmi, chociaż może być, jeśli boisz się" print x " drukowania ekranu pełnego śmieci. Ale jeśli masz informacje debugujące, takie jak drukowanie członka std::vector działa, a jeśli coś się nie powiedzie, nadal możesz sprawdzić surową pamięć za pomocą polecenia x. Ale jeśli Wiem, czego szukam, używam opcji 1-logowanie.

Zauważ, że "trudne do sprawdzenia" struktury są nie tylko STL / Boost, ale także z innych bibliotek, takich jak Qt / KDE.

 3
Author: jpalecek,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-11 17:05:12