Программирование на Visual C++

Выпуск №26 от 3 декабря 2000 г.

Здравствуйте!

Итак, вот уж и зима на дворе… Время, когда отходить от компьютера не хочется даже ненадолго ;) Правда, это если у вас в комнате достаточно тепло. В другом случае не хочется вылезать из-под трех одеял;)

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

В этой статье я очень кратко расскажу о возможностях встроенного отладчика Visual C++.

Запуск отладки

Чтобы запустить программу на отладку, нужно выбрать одну из команд меню Build->Start Debug. Обратите внимание, что команда Attach to Process позволяет подключиться к уже запущенному процессу.

Точки останова (Breakpoints)

Точки останова служат для прерывания программы, выполняемой в отладчике. Их можно привязывать к конкретной строке в коде программы, к переменной или к сообщению Windows. После того как программа прервана, её можно выполнять в пошаговом режиме или просто проанализировать значения переменных, после чего продолжить выполнение.

Чтобы установить точку останова на строку вашей программы, достаточно выбрать команду Insert/Remove Breakpoint или нажать F9. Однако гораздо больше возможностей предоставляет окно Breakpoints из меню Edit. В нижней части этого окна находится список уже поставленных точек останова (любую из них можно активизировать, отключить или удалить), а вверху расположены три вкладки, предназначенные для установки точек останова различных типов.

Вкладка Location

Здесь устанавливаются точки останова, привязанные к конкретным строкам в вашей программе. Адрес точки останова задаётся в поле Break at в виде {имя_функции, имя_файла_cpp, имя_файла_exe} @номер_строки

Для формирования адреса можно воспользоваться окном Advanced breakpoint; чтобы вызвать это окно, щелкните на стрелке справа от поля ввода и выберите пункт Advanced. Обычно достаточно задать только номер строки и имя файла с исходным кодом.

В окне Condition можно дополнительно указать условие срабатывания точки останова. Условием может быть любое выражение. Если заданное вами выражение имеет тип bool, точка останова срабатывает, когда оно истинно; в противном случае она срабатывает при изменении значения выражения.

Бывают случаи, когда точку останова нужно пропустить несколько раз, прежде чем прерывать на ней программу. Специально для этого в окне Condition предусмотрено ещё одно поле Skip count (в самом низу). С помощью этого поля можно, к примеру, пропустить 10 итераций цикла и прервать программу только на одиннадцатой.

Вкладка Data

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

Если выражение имеет смысл только в определённом контексте (например, в нём используются локальные переменные какой-либо функции), этот контекст необходимо указать с помощью всё того же окна Advanced breakpoint, но здесь уже важно указать имя функции, а не файла.

Вкладка Messages

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

LRESULT WINAPI WndProc(HWND, UINT, WPARAM, LPARAM);

В программах, использующих MFC, удобнее ставить точки останова в соответствующие обработчики сообщений.

Пошаговая отладка

После того, как программа прервана, её можно выполнять в пошаговом режиме. Для этого в отладчике предусмотрены следующие команды (из меню Debug).

Go (F5) – продолжить выполнение программы до следующей точки останова.

Step Into (F11) – выполнить одну инструкцию; если это вызов функции, точка выполнения перемещается на первую инструкцию этой функции.

Step Over (F10) – выполнить одну инструкцию; если это вызов функции, то она выполняется целиком.

Step Out (Shift+F11) – выполнять программу до возврата из текущей функции.

Run to Cursor (Ctrl+F10) – эквивалентна установке временной точки останова с последующим вызовом команды Go.

Иногда в процессе отладки возникает необходимость перенести точку выполнения. Например, вы заметили ошибку и хотите "перескочить" через неё или, наоборот, хотите вернуться немного назад и выполнить фрагмент программы ещё раз. Чтобы это сделать, установите курсор в нужном месте и выберите команду Set Next Statement из контекстного меню (или нажмите Ctrl+Shift+F10).

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

Окно Variables

В этом окне автоматически отображаются значения локальных переменных (вкладка Locals), переменных-членов класса, адресуемого указателем this (вкладка This), а также всех переменных, которые используются в предыдущей и текущей строках программы (вкладка Auto). На вкладке Auto также показываются возвращаемые значения функций.

Чтобы изменить значение переменной в окне Variables, достаточно просто два раза кликнуть на старом значении и ввести новое.

Выпадающий список Context позволяет просматривать локальные переменные любой из вызванных в данный момент функций. Кроме того, код выбранной в нём функции отображается в окне редактора.

Вы, вероятно, заметили, что отладчик "умеет" распознавать стандартные структуры данных (CString, RECT и т. п.) и показывать их содержимое в удобном виде. Оказывается, можно не только изменить представление этих структур в окне Variables, но и определить представление для собственных структур. Для этого нужно отредактировать файл autoexp.dat, расположенный в каталоге :\Common\MSDev98\Bin. Описание формата приводится в самом файле.

Окно Watch

Окно Watch позволяет просматривать значения переменных и выражений. Переменные и выражения можно размещать на любой из четырёх вкладок. Добавить переменную или выражение в окно Watch можно одним из следующих способов:

– Ввести с клавиатуры

– Перетащить из окна редактора или из окна Variables

– Добавить из окна Quick watch

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

Чтобы узнать тип переменной или выражения, нужно щёлкнуть по ним правой кнопкой и выбрать Properties из всплывающего меню.

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

Можно указать отладчику, в каком формате выводить значение переменной/выражения, используя флаги форматирования. Эти флаги добавляются к имени переменной или выражению через запятую. Большинство из них совпадает с символами форматирования функции printf: d – целое число со знаком, u – беззнаковое целое, f – число с плавающей точкой, c – символ, s – строка и т. д. Однако есть четыре флага, на которых я хочу остановиться подробнее.

Флаг wm превращает код сообщения в его название, например:

0x01,wm = WM_CREATE

Флаг wc позволяет стиль окна, например:

0x6840000,wc = _OVERLAPPEDWINDOW WS_CLIPSIBLINGS WS_CLIPCHILDREN

Флаг hr переводит коды ошибок Win32 и значения HRESULT, возвращаемые функциями COM, в удобочитаемый вид, например:

0x02,hr = 0x00000002 Системе не удается найти указанный файл.

Наконец, в Visual C++ есть числовой флаг, который позволяет просмотреть заданное количество элементов массива, адресуемого указателем (по умолчанию показывается всего один элемент). Допустим, мы выделили динамический массив из 10 целых чисел:

Int *pInt = new[10];

Чтобы просмотреть его содержимое в окне Watch, нужно ввести:

pInt,10

Псевдорегистр ERR

Как известно, получить расширенный код ошибки после вызова функций Win32 API можно с помощью GetLastError. Однако расставлять по всей программе вызовы GetLastError крайне неудобно. Поэтому в отладчике Visual C++ предусмотрен специальный псевдорегистр ERR, который всегда содержит расширенный код ошибки. Особенно удобно наблюдать значение этого регистра, использую уже знакомый нам флаг hr. Добавьте ERR,hr в окно Watch, и информация об ошибках в вызовах функций API всегда будет у вас перед глазами.

Другие окна отладчика

Окно Registers. Позволяет просматривать и изменять значения регистров процессора.

Окно Memory. Позволяет просматривать и изменять содержимое ячеек памяти.

Окно Call Stack. Показывает последовательность вызванных функций. Используя контекстное меню, можно отобразить также типы и значения параметров этих функций. К тексту любой функции можно переместиться, сделав двойной щелчок на её имени. Обратите внимание, что точки останова можно ставить прямо в этом окне.

Окно Disassembly. Показывает текст отлаживаемой программы на языке ассемблера. Иногда без помощи этого окна ошибку в программе найти не удаётся.

Диалоги

Диалоги отладчика предоставляют вам ряд дополнительных возможностей. Они вызываются из меню Debug.

Quick Watch. Имеет возможности, аналогичные возможностям окна Watch, с той разницей, что в нём можно просматривать только одну переменную за раз. Используется, когда вам не хочется добавлять переменную в окно Watch.

Exceptions. Позволяет настроить реакцию отладчика на возникновение системных и пользовательских исключений.

Threads. Показывает список активных потоков. Позволяет приостановить (suspend) или продолжить (resume) поток, а также установить на него фокус.

Modules. Показывает список загруженных модулей. Для каждого модуля выводится диапазон адресов и имя файла.

Edit and Continue

В заключение хотелось бы упомянуть о новой мощной возможности, которая появилась в Visual C++ 6.0 – Edit and Continue. С её помощью вы можете вносить изменения в код программы и перестраивать её, не прерывая сеанса отладки.

Для этого достаточно вызвать команду Apply code changes из меню Debug (или нажать Alt+F10), после того как вы подправили исходные тексты. Более того, Visual C++ может вызывать для вас эту команду автоматически. Это будет происходить, если в окне Tools->Options на вкладке Debug установить флаг Debug commands invoke Edit and Continue.

(Александр Шаргин)

Q. У меня dialog-base приложение, живет в systray. Необходимо, чтобы приложение при повторном запуске находило уже запущеный экземпляр программы и активизировало его. Я пытался сделать это через FindWindow(), в которую передается имя зарегистрированного класса окна, и заголовок окна, которое разыскивается. По заголовку я искать не могу, так как он все время у меня меняется. Следовательно, нужно искать по зарегистрированному имени класса окна. Вот тут то и начинается проблема. Я его не знаю. MFC сама их раздает dialog-based приложениям. А переопределить это имя можно было бы в PreCreateWindow(), но этот метод CDialog не наследует из CWnd. Во всех остальных методах, имя класса уже зарегистрированно, т.е. менять его поздно. Как быть?

(el-f)

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

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

A₁ Относительно вопроса, заданного в №25 данной рассылки хотелось бы сразу высказать сильное сомнение по поводу возможности его решения при помощи использования имен оконных классов. Мне кажется, что каждый экземпляр приложения в операционной системе Windows имеет, как это не пародоксально звучит, свой набор зарегистрированных оконных классов. Общность стандартных (системных) оконных классов поддерживается автоматической загрузкой в адресное пространство системных библиотек, которые, в момент своей инициализации, регистрируют свои оконные классы. Список DLL (только они позволяют делать общедоступными определенные виды окон), подгружаемых автоматом каждому приложению, хранится где-то в реестре (не помню точно где). Еще одним доводом в пользу предположения об уникальности списка зарегистрированных оконных классов каждого приложения (экземпляра приложения) служит сама процедура RegisterClass(Ex). В качестве аргумента данной процедуры выступает указатель на структуру, одним из элементов которой является указатель (адрес) на оконную процедуру. Нет 100% гарантии того, что разные DLL проекцируются в одно и то же адресное пространство всех приложений без исключений. Следовательно, адрес оконной процедуры перестает нести смысловую нагрузку. Из изложенного выше, позвольте сделать вывод: если в результате регистрации приложением оконного класса произошла ошибка типа "Оконный класс с указанным именем уже существует" это означает лишь то, что именно ЭТО приложение уже зарегистрировало подобный класс. И наоборот, если регистрация прошла успешно, то это не значит, что нет такого приложения (экземпляра приложения) которое не зарегистрировало бы оконный класс с подобным именем. Следовательно подобный подход при решении подобной проблемы невозможен.

Решить указанную проблему можно лишь при помощи объектов ядра операционной системы, объектов файловой системы (так, по моему, решаются подобные задачи в OS типа Linux/Unix) и некоторых других объектов (типа mailslot, TCP ports и наверное можно придумать что либо еще). Важно выполнение следующих условий:

1. Объекты должны быть доступны из различных приложений

2. Объекты должны быть одинаковым образом идентефицированы для всех приложений (идет отказ от дескрипторов объектов, которые актуальны только в рамках одного процесса).

3. Желательно (а может обязательно?), что бы OS поддерживала синхронизацию доступа к данным объектам.

Самый простой способ идентефикации объектов заключается в присвоении им строковых имен. Такой способ применяестся к объектам ядра, файловой системы, mailslot. TCP способ использует разименовку по номеру порта. И имя и номер имеют одно и то же значение для всех приложений. Для функции RegisterClass(Ex), похоже, не выполняется первое условие. Способ определения повторного запуска экземпляра приложения давно известен и использует объект ядра системы типа "mutex". В задаче, кроме того, требуется подать сигнал активизации первому экземпляру приложения. Пришлось модифицировать известный способ, попутно решив эту проблему для себя, и использовать объект ядра типа "event". В общем, принцип работы схемы выглядит так:

1. Попытка получить доступ к объекту ядра по имени

1.1. Доступ получить не удалось из-за отстутствия объекта с указанным именем – данный экземпляр приложения первый. Переходим к п. 2

1.2. Доступ получен – большая вероятность того что данное приложение запущено во второй раз. Почему не 100% уверенность? Делаем скидку на то, что кто то другой мог выбрать для своих нужд именно этот тип объектов и именно с этим именем :). Переходим на п. 3

2. Инициализация и активация главного окна

2.1. Создаем объект ядра с именем, использованным в п. 1

2.2. Инициализируем и запускаем приложение

2.3. Время от времени проверяем поступление сигнала о запуске второй копии приложения

3. Передача сигнала первому приложению о запуске второй копии и выход из программы.

(Владимир Голенкевич)

Очень подробный и интересный ответ, но к сожалению не совсем корректный. Насчет классов – действительно, они доступны только внутри зарегистрировавшего их процесса (в MSDN есть хорошая статья "Window Classes in Win32" by Kyle Marsh). Однако я не совсем согласен с логическими построениями автора (или понял их неправильно). Т.к. имя класса по идее уникально, то естественно, что ИМЕННО ЭТО приложение зарегистрировало класс. А как иначе?..

Вопросы вызывают еще два момента. Во первых, при создании объектов ядра НИ В КОЕМ СЛУЧАЕ не нужно сначала проверять, существует ли такой объект (п.1). Иначе можно нарваться на т.н. race conditions, описанные в вышеупомянутой статье – ситуация, когда два экземпляра стартуют почти одновременно. Получается, что одна копия проверяет, что объект не существует, и создает его. Но прежде чем она его создаст, вторая копия тоже убеждается в том, что объекта еще нет, и тоже собирается со спокойной совестью его создать. В результате первая копия успевает создать объект, а второй копии создать объект так и не удается, но это уже не важно, т.к. вторая копия все равно запускается.

Не стоит думать, что такая ситуация маловероятна. Представьте себе пользователя, который настроил Windows запускать программы по одному щелчку на ярлыке, но по привычке делает double-click…

Весь смысл объектов ядра как раз в том, что при их создании ГАРАНТИРУЕТСЯ, что никто другой в это же время не сможет создать такой же объект. Нужно сразу пытаться СОЗДАТЬ объект – и если эта операция не удается (возвращается ERROR_ALREADY_EXISTS или ERROR_ACCESS_DENIED) – вот тогда можно с уверенностью говорить о том, что запущена еще одна копия.

Во-вторых, мне не совсем понятны пункты 2.3 и 3. Мне кажется это очень неэфективным – постоянно проверять на наличие сигнала от второй копии (как я понимаю, по этому сигналу приложение должно себя активизировать). Есть способы гораздо лучше (читайте ниже).

Но (заметьте!) мы выяснили очень важную вещь: использование объектов ядра абсолютно необходимо для определения, запущена ли копия приложения или нет.

A₂ Можно например с помощью RegisterWindowMessage.

В двух словах:

1. Регистрируем сообщение.

2. Отправляем его на HWND_BROADCAST с каким нибудь кодом в wParam, (например 1) и своим hWnd в lParam (чтобы получатель знал, куда отправлять ответ)

3. Пишем обработчик нашего зарегистрированного сообщения. Он анализирует wParam, если там 1 и lParam не равен собственному hWnd, то он отсылает в ответ такое же сообщение но с кодом 2 например.(отправителя мы получили через lParam)

4. Если мы получили сообщение с кодом 2 в wParam значит уже есть запущенная копия приложения.

(Pavlik Yatsuk)

Если к ответу добавить механизм объектов ядра, то получается вариант правильный… на первый взгляд. Вот что говорит об этом способе Александр Шаргин:

"Я отказался от этого подхода, и вот почему […] Посылая сообщение с параметром HWND_BROADCAST, мы теряем доступ к возвращаемому в ответ значению. А значит, уже запущенная копия нашего приложения (если таковая есть) должна ответить также посылкой сообщения. Вопрос: кому его посылать? Главное окно во второй копии приложения ещё не создано, цикла сообщений нет… Выход один: создавать невидимое окно, и ловить в нём сообщение — кривовато…

Вариант второй: не использовать HWND_BROADCAST, а сделать EnumWindows и посылать сообщение каждому окну в отдельности. А значит писать свою CALLBACK-функцию, обработчик зарегистрированного сообщения… Тоже кривовато, мне не понравилось."

(Кстати, вариант второй как раз используется в статье;) А вот и сам его ответ:

A₃ Для начала два замечания. Во-первых, CDialog таки наследует функцию PreCreateWindow от своего предка – класса CWnd. Другой вопрос, что эта функция не вызывается в процессе создания диалогового окна. Во-вторых, MFC не регистрирует класс диалогового окна, оставляя имя, предопределённое в Windows. Вместо этого MFC передаёт адрес своей собственной диалоговой функции (AfxDlgProc) при вызове CreateDialogIndirect.

Итак, мы установили, что диалоговое окно создаётся в функции CreateDialogIndirect. Мы не можем повлиять на процесс создания окна, а значит не можем и изменить имя класса. Придётся искать обходные пути. Самый простой из них, на мой взгляд – дать диалогу "во владение" невидимое окно, для которого заголовок и имя класса известны. Затем можно найти это окно с помощью FindWindow, переместиться к самому диалогу через GetWindow и сделать на него SetForegroundWindow.

Вот фрагмент функции InitInstance, который делает всё необходимое (использование статических переменных выглядит несколько коряво – я использовал их, чтобы весь код был в одном месте, но в реальной программе лучше сделать их членами класса).

BOOL CMyApp::InitInstance() {

 …

 HWND hWnd = FindWindow("{4C1D4220-C3E5-11d4-93A8-B5D00D46136A}", NULL);

 if (hWnd != NULL) {

  hWnd = GetWindow(hWnd, GW_OWNER);

  SetForegroundWindow(hWnd);

  return FALSE;

 }

 WNDCLASS wc;

 ZeroMemory(&wc, sizeof(wc));

 wc.hInstance = AfxGetInstanceHandle();

 wc.lpfnWndProc = DefWindowProc;

 wc.lpszClassName = "{4C1D4220-C3E5-11d4-93A8-B5D00D46136A}";

 RegisterClass(&wc);

 static CMyDlg dlg;

 m_pMainWnd = &dlg;

 dlg.Create(IDD_MY_DIALOG, NULL);

 static CWnd wndDummy;

 wndDummy.CreateEx(0, "{4C1D4220-C3E5-11d4-93A8-B5D00D46136A}", "", 0, CRect(0,0,0,0), &dlg, 0);

 …

 return TRUE;

}

Обратите внимание на использование GUIDа в качестве имени класса. Он получен с помощью утилиты Guidgen (меню Tools). Вероятность того, что в системе найдутся окна с таким классом, не имеющие отношения к нашей программе, представляется ничтожно малой.

(Александр Шаргин)

А вот если к этому ответу добавить механизм mutex'ов, то получится действительно корректный способ.

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

Интересующимся этой темой я настоятельно рекомендую ознакомиться со статьей by Joseph M. Newcomer, где подробно разбираются достоинства и, главное, недостатки, каждого метода. А методов, помимо рассмотренных выше, очень много, напр. file mapping, shared variable и др. (я не стал публиковать эти ответы т.к. все эти объекты используются с одной целью, которая отлично решается с помощью mutex'ов).

Некоторые ссылались на статью в MSDN Q109175 – так вот: там используется некорректное решение!

Если вдруг кто-нибудь, кто прислал мне ответ, все еще считает его 100% правильным, прошу написать мне об этом – я никого обидеть не хотел, а в таком большом количестве ответов было легко что-то упустить. И еще: у кого есть какие соображения по этому поводу, замечания – пишите! Дискуссия получается на редкость интересная.

Q Есть диалог на нем Date Time Picker и есть соответствующая ему переменная m_Time типа CTime. Проблема в том, что если m_Time = 0, то в диалоге высвечивается 2:00:00!!?? Т.е. сдвиг на два часа. Причем если выставить 0:00:00, то будет "Assertion fault". Ну и соответственно, если установить 2:00:00, то после UpdateData() m_Time станет = 0. Скорее всего это как-то связано с часовым поясом (у меня часовой пояс +02:00). Как от этого избавиться?

(Михаил)

Это все на сегодня. Удачи вам!

(Алекс Jenter jenter@mail.ru) (Красноярск, 2000.)