Привет форумчане. Решил писать статьи по отладке программ. Мне кажется, статьи довольно полезны. Так же очень прошу выкладывать ваши мнения, так как мне это очень важно, это мои первые статьи. И так, начнем!
 А начнем с введения в проблему.
Обоснование технологии отладки.
    Все мы наверное читали многочисленные рассказы о  результатах плохого программирования: диапозон случаев распространияется от банковских ошибок в прогах, которые приводили к убыткам фондов без должной причины, до медецинских ошибок в записях или до ошибок в космических системах свяхи, которые срабатывали неверно(Был случай, какойто американский программер ошибся на 1 цифру, И ракета взорвалась). В ряде случаях серьезные увечья или осложнения со здоровьем были следствием неисправностей в общественном транспорте или неисправностей в медицинском оборудовании, которые возникали по вине программных ошибок.
     Эти проблемы часто возникают как результат багов(ошибок), которые были привнесены в программный код программистом и не были обнаружены и устранены. Чтобы минимизировать ошибки, которые возникаютпри написании программ, чрезвычайно важно сначала освоить основы хорошего программирования и далее постоянно держать их в уме. Очень хорошим источником для освоения хорошего стиля разработки и реализации программ является популярная книга Практика Программирования, написанная Кернинганом и Пайком.
     Технология хорошего программирования осваивается по мере проведения изнурительной работы с акцентированием внимания на множестве деталей. В хорошо разработанной программе будут устранены многие ошибки, но не все. Часто программный код будет содержать ошибки даже в хорошо спроектированной системе.
    После того как синтаксические ошибки были устранены, программист в большей части должен будет самостоятельно найти, так называемые "семантические" ошибки. Такие ошибки свойственны коду с правильным синтаксисом, но который все еще имеет неправильную логику. И поэтому возникают ошибки при исполнении программы. Некоторые из таких ошибок очень трудно обнаружить. Поэтому может возникнуть потребность в разработке специальных средств для их обнаружения. Оснавная цель моих статей - представить необходимые подходы и возможности, которые  позволяют найти и скорректировать семантические ошибки. Используют два наиболее действенных средства по корректированию семаетических ошибок, которые обычно встречаются в первых программах программистов, можно привести: случаи использования символа "<" вместо "<=" в условиях, определяющих завершение цикла(у самога такая ошибка на начальной стадии программирования была); случаи обращения за элементами массива, которые находятся вне области определения массива; случаи, когда программист просто забывает инициализировать переменные.
     Многие ошибки, которые возникают в ходе исполнения программы, могут быть обусловлены не логикрй программы, а связаны со значениями данных, что и приводит к проблеме. Типичный пример возникновения такой ошибки можно  проиллюстрировать в случае, когда непосредственно перед выполнением операции деления знаменатель становится равным нулю, и система выдает диагностическое сообщение об ошибки типа "program error: attempted to divide by zero.".  Подобного рода рода ошибки могут обнаруживаться и корректироваться средствами трассировки и отладчика. Средствами, которые я рекомендую в этих статьях. Ошибки могут так же обнаруживаться и автоматически, используя для этого технику обработки исключительных ситуаций, свойственную обьектно - ориентированному С++. Но этот метод выходит за пределы этих статей.
      Некоторые ошибки возникают в результате поступления на обработку программе "плохих" входных данных, а никак не по вине программиста. Однако программист ОБЯЗАН включить в свой программный код проверку наличия поступивших "плохих" входных данных с тем, чтобы выдавать сообщения об ошибках, когда будут обнаружены "плохие" данные. А в некоторых случаях, при обнаружении таких данных - завершить выполнение программы. Такие проверки часто называют "error checking".

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

нда...
ладно, подождем вторую "статью"

MAKCim, скажите что вам не понравилось во вступлении. Мне кажется что слишком сухо, как в энциклопедии или толковом словаре каком нить. Скажите, это важно.

Статья номер 2.

Методы отладки.

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

1. Ручная трассировка

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

2. Программная трассировка

     Программная трассировака использует трассировочные предложения, включенные в программы в ключевых местах программы, чтобы проследить изменения значений переменных по мере пошагового выполнения программы. Трассировку можно осуществить посредством включения потока cout в C++ по ходу расположения трассы. Предложения используются для определения текущих значений всех переменных. Расширенная трассировка допускает использование флагов и функциональных вызовов. С их помощью можно более просто включать и выключать трассировку и минимизировать объем дополнительного кода, который должен быть написан и включен в программу.

3. Системный диалоговый отладчик

     В большинстве современных сред языков программирования включен отладчик. Он представляет собой программный пакет, с помощью которого можно выполнять программу в пошаговом режиме, автоматически отслеживая изменения значений после каждого шага. Можно также установить контрольные точки, что позволяет программе избежать больших накладных расходов при выполнении участков программы вне пределов трассиовки и позволяют останавливать выполнение программы для отображения всех программных переменных и их значений.
     Все перечисленные мною методы отладки полезны и заслуживают узучения и использования. Я рекомендую начинать работу с ручной трассировкой, поскольку этот  метод заставляет вас полностью осознать программные требования и логику своей программы. Если этот метод не позволяет определить места расположения ошибок выполнения (runtime errors), я рекомендую использовать расширенную программную трассировку на основе включения в текст программы потоков cout.

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

     Вот моя 2 статья завершена. Пишите отзывы. В следующей статье мы приступим к обсуждению деталей отладки. Спасибо за внимание!
     

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



Круто, ты для кого пишешь такие предложения?)

Капитан Очевидность среди нас  


Если учесть, что на форуме задаются вопросы - как сделать из срр ехе, то наверное статья будет востребована  


странная у тебя терминология, не семантические, а логические, а так-же ошибки времени выполнения....

Тут я поспорю. Каждый называет как хочет, имхо. 

Ребят, поймите психологию человека. Я уверен многие были такие же. Лучше объясните что не так, он опыта наберется. 
Я просто вспоминаю себя, со своими тупыми вопросами. В таком возрасте (если я не ошибаюсь, автор ещё где то в 8 классе? я точно не знаю) это многим свойственно.
Никто же не может (да и нужно ли?) запрещать писать ему. 
И перенесите во флейм чтоли, мне кажется, что действительно можно много чему научить человека - при его желании

Добавлено через 1 минуту и 22 секунды
p.s. статью не читал, но на лицо много грамматических ошибок и не хороших оборотов, вроде "программер", "какойто" и т.п.

Да уж лучше удалите мои статьи, но уж во флейм не надо плз.


  

Семантика в программировании

спасибо за ссылку.

CppDevelopeR, 
сравни то, что написано в википедии
и у тебя
по сути одно и то же
но форма изложения разная
в этом у тебя, имхо, основная проблема
кроме того, пока я вижу в статьях очевидные вещи, которые в общем-то не несут особой ценности: как мне показалось, льется вода ни о чем
попытайся углубиться и рассмотреть какую-то одну часть общей темы, но сделай это подробно и детально
смысл любой статьи - синтез сведений из различных источников по определенной теме для формирования у читателей целостного представления о ней
мало знать, как работают компоненты A, B, C системы X
важно знать как работает система X при помощи компонентов A, B, C



Это сообщение отредактировал(а) MAKCim - 5.7.2008, 20:50

Хочу с уверенностью заверить, что это пока. Ну не умею я писать красивые вступления. Хоть убейте, не умею.

Добавлено через 58 секунд
Но следующие статьи, уверяю, будут достаточно интересны и познавательны.

посмотрим

Постараюсь оправдать ожидания.