отладка C ++ по сравнению с отладкой C

Question

HI,

Я обычно программист на Си.Я регулярно отлаживаю программы на C в среде unix, используя такие инструменты, как gdb, dbx.я никогда не делал отладку больших приложений C ++.Это сильно отличается от того, как мы отлаживаем в C. Теоретически я достаточно хорош в C ++, но у меня никогда не было возможности отлаживать программы на C ++.Я также не уверен в том, с какими техническими проблемами мы сталкиваемся в c ++, которые приведут разработчика к включению отладчика для обнаружения проблемы.с какими общими проблемами мы сталкиваемся в C ++, из-за которых отладчик запускается

с какими проблемами может столкнуться программист ac при отладке программы на C ++?Это сложно и сложно по сравнению с C?

Answer 1

Это в основном то же самое.

Просто помните, что при установке точек останова вручную необходимо полностью квалифицировать имя метода как с пространством (именами) имен, так и с классом (как результат, некоторые находят, что легчеиспользуйте номера строк для определения точек останова)

Не забывайте, что вызовы деструкторов невидимы в источнике, но вы все равно можете войти в них в конце блока.

Answer 2

Несколько незначительных отличий:

При вводе полного символа, такого как foo::bar::fum(args) в оболочке GDB, вы должны начать с одинарной кавычки, чтобы GDB распознал его и вычислил завершения.

Как уже говорили другие, библиотечные шаблоны выставляют свои внутренние компоненты в отладчике. Вы можете довольно легко пробираться в std::vector, но пробираться через std::map, возможно, не мудрый способ провести время.

Агрессивное и обильное встраивание, распространенное в программах на C ++, может привести к тому, что в одной строке кода будут казаться бесконечные шаги. Такие вещи, как shared_ptr, могут быть особенно раздражающими, потому что каждый доступ к указателю расширяется внутри встроенных шаблонов. Ты никогда не привыкнешь к этому.

Если у вас есть тонна перегруженных имен символов, выбор того, который вы хотите из завершения чтения строки, может быть неприятным. (Какой "фу" ты хотел? Все они? Только эти двое?)

Answer 3

У GDB непростое прошлое в отношении отладки c ++.Какое-то время он не мог эффективно ломаться внутри конструкторов / деструкторов.

Кроме того, контейнер stl было чрезвычайно трудно проверить в gdb.std::string было больно, но в целом работоспособно.std::map было настолько сложно, что я обычно добавлял операторы печати, если не было другого пути.

Проблема конструктора / деструктора была исправлена ​​в течение нескольких лет.в GDB 7.0.

У вас могут возникнуть проблемы с библиотеками boost.В свое время мне было трудно заставить GDB давать мне оценки содержимого shared_ptr.

Так что я думаю, что отладка вашего собственного C ++ не так уж и сложна, это отладка сторонних классов и шаблонного кода, которыйбыть проблемой.

Answer 4

На самом деле довольно много проблем, но это также зависит от используемого отладчика, его версий и т. Д .:

1. Доступ к отдельным членам шаблонизированного класса нелегок
2. Обработка исключений является проблемой - я видел, что отладчики лучше справляются с setjmp / longjmp
3. Установка точек останова с помощью чего-то вроде obj1 == obj2, где они не являются типами POD, может не работать

Что мне нравится в отладчиках, так это то, что для доступа к закрытым / защищенным членам класса мне не нужно вызывать процедуры get; просто [obj-name]. [var-name] достаточно хорошо.

Arpan

Answer 5

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

Answer 6

C ++ объекты могут быть иногда сложнее анализировать. Также, поскольку данные иногда вкладываются в несколько классов (на нескольких уровнях), может потребоваться некоторое время, чтобы «развернуть» их (как уже было сказано другими в этой теме). Трудно сказать, так как это очень сильно зависит от используемых функций C ++, стиля программирования и сложности задачи для анализа (на самом деле это не зависит от языка).

IMO: если кто-то очень часто нуждается в отладке, ему следует пересмотреть свой стиль программирования. Обычно для меня это все об обработке ошибок в конце. Если программа ведет себя неожиданно, ваши журналы ошибок должны содержать достаточно информации, чтобы восстановить то, что произошло на любом этапе.

Это также дает вам преимущество в том, что вы сможете «отлаживать» проблемы в автономном режиме позже, когда ваша программа будет отправлена ​​конечным пользователям.