Отладка приложений

       

Поиск решения


Путь к решению проблемы ограничения предложений трассировки был очень извилистым. Первой мыслью было применение условной компиляции, чтобы каждый исходный файл имел связанную с ним директиву #define. Чтобы увидеть предложения трассировки для конкретного файла или набора файлов, нужно просто вставить в исходный код директиву #define и выполнить компиляцию. Такой подход, конечно, работал бы, но повторная компиляция программы только для включения или выключения предложений трассировки в исходном файле все-таки не представлялась достаточно эффективной.

Другим возможным решением было включение в программу уникального макроса трассировки. Пытаясь решить проблему слишком большого количества трассировок в огромной команде разработчиков, я опробовал и такой подход. Каждая "подкоманда" получала уникальный макрос трассировки для своей специфической секции проекта. Подобный подход реализует библиотека классов MFC (Microsoft Foundation Class), внутренняя трассировка которой включается с помощью специальной программы TRACER.EXE. Предложения внутренней трассировки MFC проверяют глобальную переменную-флажок, и если бит, назначенный подсистеме, установлен, в окне Output появляются предложения трассировки. В моей большой команде подход с уникальным макросом некоторое время работал, но постепенно перестал применяться, потому что MFC-мастера (wizards) сами генерировали специальный трассировочный макрос, и разработчики забывали использовать свой уникальный макрос. Чтобы заставить разработчиков использовать правильный макрос, я пробовал бороться с этой проблемой, отменяя определение макроса TRACE в исходных файлах (с помощью директивы #undef), но обнаружил, что наличие макросов, устанавливаемых и мастером, и еще кем-то, сильно раздражает разработчика. Другая проблема состоит в том, что этот макрос не так просто расширить. В общем, нужно тратить довольно много времени на предварительный перенос макроса трассировки с проекта на проект. Становится также проблемой поддержка таких макросов при изменении архитектуры программы и перемещении кода из одной подсистемы в другую. Кроме того, подход с уникальным макросом не работает с программами на Visual Basic.

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

В отличие от других глав этой книги, проблемы, описанные в предыдущем разделе, я решал независимо друг от друга. Чтобы построить систему, которая ограничивает количество предложений трассировки, нужно только связать индивидуальные решения вместе. Кажется, мне удалось достичь заветной цели повторного использования кода (см. ниже раздел "Реализация LIMODS" данной главы).



Содержание раздела