Инструментальная (диагностическая) библиотека для C++

Вы также можете проверить libcwd:

Libcwd — это потокобезопасная полнофункциональная библиотека поддержки отладки для разработчиков C++. Он включает в себя вывод отладки на основе ostream с настраиваемыми каналами отладки и устройствами, мощную поддержку отладки с выделением памяти, а также поддержку во время выполнения для печати исходного файла: информации о номере строки и разделенных именах типов.

• Список функций
• Учебник
• Краткий справочник
• Справочное руководство

Кроме того, еще одна интересная библиотека ведения журналов — pantheios:

Pantheios — это библиотека API ведения журналов C/C++ с открытым исходным кодом, предлагающая оптимальное сочетание 100%-ной безопасности типов, эффективности, универсальности и расширяемости. Он прост в использовании и расширении, обладает высокой переносимостью (не зависит от платформы и компилятора) и, что лучше всего, поддерживает традицию C: вы платите только за то, что используете.

Для этой цели я обычно использую журналирование. Log4cxx прекрасно работает.

Если вы занимаетесь отладкой, возможно, используйте отладчик. Сценарии GDB довольно легко написать и использовать. Поддерживать их параллельно вашему коду может быть непросто.

Изменить - добавление анекдота:

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

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

Одним из недостатков было то, что сгенерированные мной gdb-скрипты не имели явного отношения к исходному коду; исходный файл и скрипт gdb разрабатывались независимо. В идеале изменения в исходном файле должны влиять на скрипт gdb и обновлять его. Одна из идей состоит в том, чтобы поместить комментарии в специальном формате в код и сделать так, чтобы язык сценариев выполнял проход по исходным файлам для создания файла сценария отладчика для исходного файла. Наконец, пусть makefile выполняет этот сценарий во время цикла сборки.

Размышлять о потенциале использования GDB для этой цели — забавное упражнение, но я должен признать, что, вероятно, существуют лучшие решения на уровне кода.

Если вы запускаете свое приложение в Linux, вы можете использовать «ulimit» для создания ядра при сбое приложения (или assert(false) или kill -6 ), позже вы можете отлаживать с помощью gdb (gdb -c core_file binary_file) и анализировать стек.

Салу2.

ПД. для профилирования используйте gprof