Чтение онлайн

Другие инструменты сходны по природе с описанными ранее.

Замещающая

библиотека, которая не нуждается в особой компиляции и может использоваться с С++. См. .

Марка Мораеса (Mark Moraes)

Старинная, но полнофункциональная библиотека замещения

, предоставляющая возможности профилирования, трассировки и отладки. Вы можете получить ее с .

Пакет с большими возможностями настройки для отладки памяти и тестирования. См

.

Пакет, требующий использования специального заголовочного файла и опций времени компилирования. См.

.

«Не просто еще один отладчик malloc» (Not Just Another Malloc Debugger). Эта библиотека не требует специальной компоновки с приложением; вместо этого она использует

для замены стандартных процедур. См. .

Похож на Electric Fence, но со многими дополнительными опциями. См.

.

Почти все из этих пакетов используют для точной настройки своего поведения переменные окружения. В таблице 15.1 на основе статей из Linux Journal сделана сводка различных пакетов.

Таблица 15.1. Сводка особенностей инструментов памяти

Инструмент	ОС	Заголовочный файл	Модуль/ программа	Многопоточность
ccmalloc	Многотипная	Нет	Программа	Нет
dmalloc	Многотипная	Необязательно	Программа	Да
efence	Многотипная	Нет	Программа	Нет
memwatch	Многотипная	Да	Программа	Нет
Moraes	Многотипная	Необязательно	Программа	Нет
mpatrol	Многотипная	Нет	Программа	Да
mtrace	Linux (GLIBC)	Да	Модуль	Нет
njamd	Многотипная	Нет	Программа	Нет
valgrind	Linux (GLIBC)	Нет	Программа	Да
yamd	Linux, DJGPP	Нет	Программа	Нет

Как видно, для отладки проблем динамической памяти доступен ряд выборов. На системах GNU/Linux и BSD один или более из этих инструментов, возможно, уже установлены, что избавляет вас от хлопот по их загрузке и построению.

Полезно также использовать для своей программы несколько инструментов подряд. Например,

для обнаружения не освобождаемой памяти, a Electric Fence для перехвата доступа к недействительной памяти.

В оригинальном С компилятор не мог проверить, соответствуют ли параметры, переданные в вызове функции, списку параметров в определении функции; прототипов не было. Это часто вело к неуловимым ошибкам, поскольку ошибочный вызов функции мог вызывать лишь частично ошибочные результаты, которые проходили незамеченными во время тестирования, или мог даже вообще не появиться во время тестирования. Например:

Если программа, содержащая этот фрагмент, никогда не вызывается с ошибочным числом аргументов,

, в которой отсутствует первый аргумент , также никогда не вызывается.

Программа V7

была предназначена для решения таких проблем. Она делала два прохода через все файлы программы, сначала собирая сведения об аргументах функций, а затем сравнивая вызовы функций с собранной информацией. Особые файлы «библиотеки » предоставляли сведения о функциях стандартных библиотек, так что их также можно было проверить, lint проверяла также другие сомнительные конструкции.

С появлением в стандартном С прототипов необходимость в

уменьшилась, но не исчезла совсем, поскольку C89 все еще допускает объявления функций в старом стиле.

Вдобавок, многие другие аспекты программы можно проверять статически, т.е. путем анализа исходных текстов.

Программа

(Secure Programming Lint — Lint для безопасного программирования) [186] является современным обновлением . Она предусматривает слишком много опций и возможностей, чтобы перечислять их здесь, но ее стоит исследовать.

Следует знать об одной особенности подобных

программ, которая заключается в том, что они выводят целый поток предупреждающих сообщений. Многие из сообщаемых предупреждений в действительности безвредны. В таких случаях инструменты допускают использование специальных комментариев, сообщающих. «Да, я знаю об этом, это не проблема», лучше всего работает, когда вы предоставляете в своем коде большое количество подобных примечаний.

является мощным, но сложным инструментом; выделение некоторого времени на изучение его использования, а затем частое его использование поможет сохранить ваш код ясным.

Разработка программного обеспечения содержит элементы и искусства, и науки, это одна сторона того, что делает ее такой восхищающей и стимулирующей профессией. Данный раздел вводит в тему тестирования программного обеспечения, которая также включает в себя и искусство, и науку; таким образом, это несколько более общий и высокий уровень (читай: «на который можно махнуть рукой»), чем остальная часть данной главы.

Тестирование программ является неотъемлемой частью процесса разработки программного обеспечения. Весьма маловероятно, что программа заработает правильно на 100 процентов при первой компиляции. Программа не несет ответственности за свою правильность; за это отвечает автор программы. Одним из самых важных способов проверки того, что программа работает так, как предполагалось, является ее тестирование.

Один из способов классификации различных видов тестов следующий:

Тесты модулей (Unit tests)

Это тесты, которые вы пишете для каждого модуля или функционального компонента своей программы. В качестве части работы может потребоваться также создать окружение (scaffolding) — код, предназначенный для предоставления поддерживающего каркаса, чтобы запустить модуль в виде отдельной программы.

Важно спроектировать тесты для каждого функционального компонента во время его разработки. Это помогает прояснить проектирование особенностей; знание того, как это тестировать, помогает определить, что следует и что не следует делать в первую очередь.