Отладка лучших практик для С++ STL/Boost с gdb

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

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

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

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

Ответ 1

Возможно, это не тот "подсказка", которую вы искали, но я должен сказать, что мой опыт после нескольких лет переезда с С++ и STL на С++ и boost и STL заключается в том, что теперь я трачу намного меньше времени на GDB, чем я привык. Я поставил это на несколько вещей:

повысить интеллектуальные указатели (в частности, "общий указатель" и контейнеры-указатели, когда требуется производительность). Я не помню, как в последний раз мне приходилось писать явное удаление (delete - это "goto" С++ IMHO). Там идет много времени GDB отслеживания недопустимых и утечки указателей.
boost наполнен проверенным кодом для вещей, которые вы, вероятно, взломали бы в меньшей степени. например, boost::bimap отлично подходит для общей схемы логики кэширования LRU. Там идет еще одна куча времени GDB.
Принятие unittesting. boost::test Макросы AUTO означают абсолютное отклонение для настройки тестовых примеров (проще, чем CppUnit). Это захватывает много материала задолго до того, как оно будет встроено во все, что вам нужно, чтобы подключить отладчик.
В связи с этим инструменты, такие как boost::bind, облегчают проектирование для тестирования. например, алгоритмы могут быть более общими и менее привязаны к типам, в которых они работают; это упрощает их подключение к тестовым прокладкам/прокси-серверам и т.д. (что и тот факт, что подверженность повышенному шаблону-тастичности побуждает вас "осмеливаться шаблонировать" вещи, которые вы никогда бы не рассмотрели раньше, давая аналогичные преимущества тестирования).
boost::array. "C array", с проверкой диапазона в отладочных сборках.
boost наполнен отличным кодом, который вы не можете помочь, но учитесь на

Ответ 2

Вы можете посмотреть:

Проверка содержимого стандартного контейнера (std:: map) с помощью gdb

Ответ 3

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

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

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

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