Рекомендации по отладке для C ++ STL / Boost с помощью gdb - PullRequest
Новая
       21

Рекомендации по отладке для C ++ STL / Boost с помощью gdb

46 голосов
/ 11 января 2009

Отладка с помощью gdb, любой код на C ++, использующий STL / boost, все еще остается кошмаром. Любой, кто использовал GDB с STL, знает это. Например, см. Примеры прогонов некоторых сеансов отладки в коде здесь .

Я пытаюсь уменьшить боль, собирая подсказки. Не могли бы вы прокомментировать советы, которые я собрал ниже (особенно те, которые вы использовали, и любые изменения, которые вы бы порекомендовали для них) - я перечислил советы, которые уменьшают порядок технических деталей.

  • Кто-нибудь использует "Stanford GDB STL utils" и "UCF GDB utils" ? Есть ли такие утилиты для повышения структуры данных? Вышеприведенные утилиты, кажется, не могут использоваться рекурсивно, например, для распечатки вектора boost :: shared_ptr разборчивым способом в рамках одной команды.
  • Напишите ваш файл .gdbinit. Включите, например, связанные с C ++ beautifiers, перечисленные в нижней части утилит UCF GDB.
  • Использовать проверенную / отладочную библиотеку STL / Boost, например STLport.
  • Использовать ведение журнала (например, как описано здесь )

Обновление : GDB имеет новую ветку C ++ .

Ответы [ 3 ]

15 голосов
/ 12 января 2009

Возможно, это не тот «совет», который вы искали, но я должен сказать, что мой опыт после нескольких лет перехода с C ++ и STL на C ++ & boost & STL заключается в том, что я сейчас трачу лот меньше времени в ГБД, чем раньше. Я объясняю это несколькими вещами:

  • усиление интеллектуальных указателей (в частности, «общего указателя» и контейнеров указателей, когда требуется производительность). Я не могу вспомнить, когда в последний раз мне приходилось писать явное удаление (удаление - это «переход» в C ++ IMHO). Много времени GDB отслеживает неверные и текущие указатели.
  • boost полон проверенного кода для вещей, которые вы, вероятно, взломали бы вместе с более низкой версией. Например, boost::bimap отлично подходит для общей схемы логики кэширования LRU. Там идет еще одна куча времени GDB.
  • Принятие юнит-теста. Макросы AUTO boost::test означают, что установка контрольных примеров - абсолютная пустяк ( проще, чем CppUnit ). Это ловит много вещей задолго до того, как оно будет встроено во что-то, к чему вы должны присоединить отладчик.
  • В связи с этим такие инструменты, как boost::bind, упрощают разработку для тестирования. например, алгоритмы могут быть более общими и менее связанными с типами, с которыми они работают; это облегчает включение их в тестовые прокладки / прокси / фиктивные объекты и т. д. (и тот факт, что воздействие на шаблонность T Boost побудит вас «осмеливаться шаблонировать» вещи, которые вы никогда раньше не рассматривали, принося аналогичные преимущества при тестировании).
  • boost::array. Производительность "массива C" с проверкой диапазона в отладочных сборках.
  • boost полон отличного кода, который вы не можете не узнать из
5 голосов
/ 11 января 2009
3 голосов
/ 11 января 2009

Я думаю, что самый простой и самый оптимальный вариант - использовать ведение журнала (ну, на самом деле я использую отладочные отпечатки, но я думаю, что это не главное). Самым большим преимуществом является то, что вы можете проверять данные любого типа, много раз за выполнение программы, а затем искать их в текстовом редакторе, чтобы найти интересные данные. Обратите внимание, что это очень быстро. Недостаток очевиден, вы должны предварительно выбрать данные, которые вы хотите регистрировать и места, где регистрировать. Однако это не такая серьезная проблема, потому что вы обычно знаете, где в коде происходят плохие вещи (а если нет, то вы просто добавите проверки исправности тут и там и тогда, вы будете знать).

Проверенные / отладочные библиотеки хороши, но они лучше в качестве инструмента тестирования (например, запустите его и посмотрите, делаю ли я что-то не так), и не так хороши в отладке конкретной проблемы. Они не могут обнаружить ошибку в коде пользователя.

В противном случае я использую обычный GDB. Это не так плохо, как кажется, хотя это может произойти, если вы напуганы "print x" печатью ненужного мусора. Но, если у вас есть отладочная информация, например, печать элемента работы std::vector и, если что-то не получается, вы все равно можете проверить необработанную память с помощью команды x. Но если я знаю, что я ищу, я использую вариант 1 - ведение журнала.

Обратите внимание, что "трудными для проверки" структурами являются не только STL / Boost, но и другие библиотеки, такие как Qt / KDE.

...