Учебник-сайт «LearnCpp.com»: прочел главу 3 (отладка программ на C++)
Начало:
1. Учебник-сайт «Learncpp.com», прочел главу 0 (вводная)
2. Учебник-сайт «LearnCpp.com»: прочел главу 1 (основы)
3. Учебник-сайт «LearnCpp.com»: прочел главу 2 (основы: функции и файлы с кодом)
Глава 3 «Debugging C++ Programs» состоит из 11 подглав (условно их можно назвать «уроками»): с 3.1 по 3.10 и резюмирующей «3.x».
В бумажные учебники по языку C++, которые я читал раньше, информацию о работе с инструментами различных сред разработки обычно либо вообще не включали, либо запихивали куда-нибудь поглубже, в приложения, в очень урезанном виде. По работе с отладчиком в те учебники вообще практически ничего не включали. На обсуждаемом сайте-учебнике разнообразным приемам отладки и, в частности, работе с отладчиком, посвящена целая глава. Это очень удобно и полезно.
Автор сайта-учебника поместил эту главу в начало учебника, чтобы при изучении основной части учебника читатель уже понимал, как можно производить отладку программ и какие инструменты для этого можно использовать.
* * *
В подглаве 3.1 «Syntax and semantic errors» рассказано о делении ошибок на синтаксические (которые обычно отлавливаются статическими анализаторами или компиляторами) и семантические (смысловые), которые приходится отлавливать программисту, потому что автоматически такие ошибки обычно отловить не получается.
В подглаве 3.2 «The debugging process» (процесс отладки) рассказано о том, как можно распланировать поиск ошибки в программе. Подглава рассчитана на тех, кто раньше никогда не искал ошибку в программе (хотя опытным программистам, думаю, тоже не повредит почитать про основы) и не знает, с какого конца взяться за эту проблему, с чего начать. Грубо говоря план исправления ошибки состоит из следующих пунктов: найти место с ошибкой, понять причину ошибки, определить исправление ошибки, сделать исправление в программе, произвести повторное тестирование программы (предполагается, что при написании программы было проведено первое тестирование, но оно каким-то образом пропустило ошибку).
В подглаве 3.3 «A strategy for debugging» (стратегия отладки) автор описывает разные способы отладки. Например, один из самых простейших способов отладки - визуальный осмотр исходного кода. Другой способ поиска ошибки - запуская программу на выполнение множество раз, можно попытаться найти условия для воспроизведения ошибки, а затем, проанализировав эти условия, можно попытаться догадаться, в чем кроется проблема. Как только программист понимает, как воспроизвести проблему, он может попытаться найти место в исходном коде, где находится ошибка, с помощью простой стратегии, которую условно можно назвать «больше-меньше» (вы закомментируете в исходном коде разные места и запускаете программу, проверяя, ошибка всё еще происходит или уже нет).
В подглаве 3.4 «Basic debugging tactics» (базовые тактики отладки) описаны некоторые полезные тактики. Например, закомментирование/раскомментирование кусков исходного кода. Вставка отладочных сообщений, сообщающих о ходе выполнения программы, с помощью их вывода в поток std::cerr. Вывод отладочных сообщений со значениями переменных в определенные моменты исполнения программы. В конце подглавы перечисляются недостатки отладки с помощью вставки отладочных сообщений в исходный код.
В подглаве 3.5 «More debugging tactics» (дополнительные тактики отладки) автор приводит некоторые способы улучшения базовых тактик отладки, призванные решить (или хотя бы смягчить) перечисленные в конце предыдущей подглавы проблемы. Например, для того, чтобы не вставлять/удалять постоянно отладочные сообщения, их можно включить внутрь условных директив препроцессора (вроде #ifdef и #endif). Альтернативный подход: использование так называемого «регистратора» (logger). Это инструмент (библиотека функций), с помощью которого можно вставлять отладочные сообщения в программу и они будут записываться в отдельный файл-журнал (log). В качестве примера работы с регистратором приведен пример работы с библиотекой «plog». У меня есть два отдельных поста, касающихся этой темы:
1. C++: включение заголовков на примере библиотеки «plog», ч.1
2. C++: включение заголовков на примере библиотеки «plog», ч.2 (окончание)
В подглаве 3.6 «Using an integrated debugger: Stepping» автор начинает описание работы со встроенным отладчиком (под «встроенным» имеется в виду, что описываемый отладчик обычно встроен в редактор кода или интегрированную среду разработки). Встроенный отладчик был придуман для того, чтобы избавиться от проблем описанных ранее «ручных» способов отладки. Описан сам отладчик и как его можно настроить в нескольких популярных средах разработки. Команды разных встроенных отладчиков часто очень похожи. Известный набор команд встроенного отладчика для пошагового исполнения программы по-английски называют словом «stepping». В этот набор команд входят команды «step into» (шаг со входом), «step over» (шаг с обходом), «step out» (шаг с выходом) и некоторые другие, менее популярные. Каждая команда рассмотрена на примере, показано, как эти команды применять в нескольких популярных средах разработки.
В подглаве 3.7 «Using an integrated debugger: Running and breakpoints» продолжается описание работы со встроенным отладчиком, вводятся дополнительные инструменты отладки. Управление ходом выполнения программы: команда «run to cursor» (выполнить до курсора) и команда «continue» (она же - «start») - для запуска выполнения программы (или продолжения выполнения после временной остановки). Точки останова (breakpoint). Команда «set next statement» (установить следующее утверждение), с помощью которой можно «перепрыгивать» некоторые фрагменты исходного кода при исполнении или возвращать исполнение назад.
В подглаве 3.8 «Using an integrated debugger: Watching variables» продолжается описание работы со встроенным отладчиком. Описано, как можно поставить значение переменной на отслеживание (watch). Можно просмотреть значения переменных в режиме отладки на данном шаге, наведя указателем мыши на нужную переменную (в популярных средах разработки обычно есть такая возможность). Можно воспользоваться инструментом «быстрого просмотра» (QuickWatch). Самый удобный инструмент для этого - отдельное окно с переменными, за которыми установлено наблюдение (watch window). В этом окне можно задавать не только имена переменных, но и выражения с переменными. Кроме того, во многих популярных средах разработки есть отдельное окно для наблюдения за значениями всех переменных (в первую очередь, локальных).
В подглаве 3.9 «Using an integrated debugger: The call stack» заканчивается описание работы со встроенным отладчиком. Здесь описано, что такое «стек вызовов» (call stack) и описано, как применять отдельное окно отладчика, в котором отслеживается текущее содержимое стека вызовов (call stack window). Подробно на примерах показано, как пользоваться этим окном в нескольких популярных средах разработки.
В подглаве 3.10 «Finding issues before they become problems» автор рассказывает, что можно сделать в своей программе для профилактики ошибок. Описано, что можно сделать, чтобы не совершать ошибки (совершать их как можно меньше). Что такое «рефакторинг исходного кода» и для чего его делают. Введение в «защитное программирование». Как находить ошибки быстро. Введение в понятие «тестовые функции» и в «модульное тестирование». Введение в так называемые «ограничения» (constraints). Инструменты для статического анализа исходного кода (linters).
Наконец, в подглаве «3.x» приводится очень короткий обзор основных терминов и тем, рассмотренных в третьей главе. В конце подглавы дано несколько несложных заданий для некоторой практики со встроенным отладчиком.
1. Учебник-сайт «Learncpp.com», прочел главу 0 (вводная)
2. Учебник-сайт «LearnCpp.com»: прочел главу 1 (основы)
3. Учебник-сайт «LearnCpp.com»: прочел главу 2 (основы: функции и файлы с кодом)
Глава 3 «Debugging C++ Programs» состоит из 11 подглав (условно их можно назвать «уроками»): с 3.1 по 3.10 и резюмирующей «3.x».
В бумажные учебники по языку C++, которые я читал раньше, информацию о работе с инструментами различных сред разработки обычно либо вообще не включали, либо запихивали куда-нибудь поглубже, в приложения, в очень урезанном виде. По работе с отладчиком в те учебники вообще практически ничего не включали. На обсуждаемом сайте-учебнике разнообразным приемам отладки и, в частности, работе с отладчиком, посвящена целая глава. Это очень удобно и полезно.
Автор сайта-учебника поместил эту главу в начало учебника, чтобы при изучении основной части учебника читатель уже понимал, как можно производить отладку программ и какие инструменты для этого можно использовать.
* * *
В подглаве 3.1 «Syntax and semantic errors» рассказано о делении ошибок на синтаксические (которые обычно отлавливаются статическими анализаторами или компиляторами) и семантические (смысловые), которые приходится отлавливать программисту, потому что автоматически такие ошибки обычно отловить не получается.
В подглаве 3.2 «The debugging process» (процесс отладки) рассказано о том, как можно распланировать поиск ошибки в программе. Подглава рассчитана на тех, кто раньше никогда не искал ошибку в программе (хотя опытным программистам, думаю, тоже не повредит почитать про основы) и не знает, с какого конца взяться за эту проблему, с чего начать. Грубо говоря план исправления ошибки состоит из следующих пунктов: найти место с ошибкой, понять причину ошибки, определить исправление ошибки, сделать исправление в программе, произвести повторное тестирование программы (предполагается, что при написании программы было проведено первое тестирование, но оно каким-то образом пропустило ошибку).
В подглаве 3.3 «A strategy for debugging» (стратегия отладки) автор описывает разные способы отладки. Например, один из самых простейших способов отладки - визуальный осмотр исходного кода. Другой способ поиска ошибки - запуская программу на выполнение множество раз, можно попытаться найти условия для воспроизведения ошибки, а затем, проанализировав эти условия, можно попытаться догадаться, в чем кроется проблема. Как только программист понимает, как воспроизвести проблему, он может попытаться найти место в исходном коде, где находится ошибка, с помощью простой стратегии, которую условно можно назвать «больше-меньше» (вы закомментируете в исходном коде разные места и запускаете программу, проверяя, ошибка всё еще происходит или уже нет).
В подглаве 3.4 «Basic debugging tactics» (базовые тактики отладки) описаны некоторые полезные тактики. Например, закомментирование/раскомментирование кусков исходного кода. Вставка отладочных сообщений, сообщающих о ходе выполнения программы, с помощью их вывода в поток std::cerr. Вывод отладочных сообщений со значениями переменных в определенные моменты исполнения программы. В конце подглавы перечисляются недостатки отладки с помощью вставки отладочных сообщений в исходный код.
В подглаве 3.5 «More debugging tactics» (дополнительные тактики отладки) автор приводит некоторые способы улучшения базовых тактик отладки, призванные решить (или хотя бы смягчить) перечисленные в конце предыдущей подглавы проблемы. Например, для того, чтобы не вставлять/удалять постоянно отладочные сообщения, их можно включить внутрь условных директив препроцессора (вроде #ifdef и #endif). Альтернативный подход: использование так называемого «регистратора» (logger). Это инструмент (библиотека функций), с помощью которого можно вставлять отладочные сообщения в программу и они будут записываться в отдельный файл-журнал (log). В качестве примера работы с регистратором приведен пример работы с библиотекой «plog». У меня есть два отдельных поста, касающихся этой темы:
1. C++: включение заголовков на примере библиотеки «plog», ч.1
2. C++: включение заголовков на примере библиотеки «plog», ч.2 (окончание)
В подглаве 3.6 «Using an integrated debugger: Stepping» автор начинает описание работы со встроенным отладчиком (под «встроенным» имеется в виду, что описываемый отладчик обычно встроен в редактор кода или интегрированную среду разработки). Встроенный отладчик был придуман для того, чтобы избавиться от проблем описанных ранее «ручных» способов отладки. Описан сам отладчик и как его можно настроить в нескольких популярных средах разработки. Команды разных встроенных отладчиков часто очень похожи. Известный набор команд встроенного отладчика для пошагового исполнения программы по-английски называют словом «stepping». В этот набор команд входят команды «step into» (шаг со входом), «step over» (шаг с обходом), «step out» (шаг с выходом) и некоторые другие, менее популярные. Каждая команда рассмотрена на примере, показано, как эти команды применять в нескольких популярных средах разработки.
В подглаве 3.7 «Using an integrated debugger: Running and breakpoints» продолжается описание работы со встроенным отладчиком, вводятся дополнительные инструменты отладки. Управление ходом выполнения программы: команда «run to cursor» (выполнить до курсора) и команда «continue» (она же - «start») - для запуска выполнения программы (или продолжения выполнения после временной остановки). Точки останова (breakpoint). Команда «set next statement» (установить следующее утверждение), с помощью которой можно «перепрыгивать» некоторые фрагменты исходного кода при исполнении или возвращать исполнение назад.
В подглаве 3.8 «Using an integrated debugger: Watching variables» продолжается описание работы со встроенным отладчиком. Описано, как можно поставить значение переменной на отслеживание (watch). Можно просмотреть значения переменных в режиме отладки на данном шаге, наведя указателем мыши на нужную переменную (в популярных средах разработки обычно есть такая возможность). Можно воспользоваться инструментом «быстрого просмотра» (QuickWatch). Самый удобный инструмент для этого - отдельное окно с переменными, за которыми установлено наблюдение (watch window). В этом окне можно задавать не только имена переменных, но и выражения с переменными. Кроме того, во многих популярных средах разработки есть отдельное окно для наблюдения за значениями всех переменных (в первую очередь, локальных).
В подглаве 3.9 «Using an integrated debugger: The call stack» заканчивается описание работы со встроенным отладчиком. Здесь описано, что такое «стек вызовов» (call stack) и описано, как применять отдельное окно отладчика, в котором отслеживается текущее содержимое стека вызовов (call stack window). Подробно на примерах показано, как пользоваться этим окном в нескольких популярных средах разработки.
В подглаве 3.10 «Finding issues before they become problems» автор рассказывает, что можно сделать в своей программе для профилактики ошибок. Описано, что можно сделать, чтобы не совершать ошибки (совершать их как можно меньше). Что такое «рефакторинг исходного кода» и для чего его делают. Введение в «защитное программирование». Как находить ошибки быстро. Введение в понятие «тестовые функции» и в «модульное тестирование». Введение в так называемые «ограничения» (constraints). Инструменты для статического анализа исходного кода (linters).
Наконец, в подглаве «3.x» приводится очень короткий обзор основных терминов и тем, рассмотренных в третьей главе. В конце подглавы дано несколько несложных заданий для некоторой практики со встроенным отладчиком.