Продвинутая отладка приложений

Я немного систематизировал свой опыт разработки приложений, а точнее отладки. За годы работы я заметил, что правильная и эффективная отладка может существенно повысить качество приложений. Статьи, в которых я изложил свой опыт можно найти по адресу http://www.devdoc.ru/index.php/content/view/debugging_p1.htm

Помимо отладки я освятил некоторые приемы по работе с отладчиком среды MS VS .Net 2003. Думаю, это будет полезно не только начинающим, но и гуру. Всегда можно найти что-то новое в привычных вещах.

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

ЗЫ: движок сайта в процессе разработки, так что ругайте господа, ругайте!

Здравствуйте, Kudinov Alexander, Вы писали:

KA>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.

Реферат по программизму? Честное слово, по-другому назвать не получается.

Здравствуйте, alexeiz, Вы писали:

A>Здравствуйте, Kudinov Alexander, Вы писали:

KA>>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.

A>Реферат по программизму? Честное слово, по-другому назвать не получается.

Может быть и реферат. К сожалению за 3 года проведения собеседований я выяснил, что 80% кандидатов на должность программиста С++ не знает этих азов.

Я с удовольствием улучшу содержание статей, если критика будет более конструктивная. Что бы вы хотели видеть?

Здравствуйте, Kudinov Alexander, Вы писали:

KA>Продвинутая отладка приложений

KA>Я немного систематизировал свой опыт разработки приложений, а точнее отладки. За годы работы я заметил, что правильная и эффективная отладка может существенно повысить качество приложений. Статьи, в которых я изложил свой опыт можно найти по адресу http://www.devdoc.ru/index.php/content/view/debugging_p1.htm

KA>Помимо отладки я освятил некоторые приемы по работе с отладчиком среды MS VS .Net 2003. Думаю, это будет полезно не только начинающим, но и гуру. Всегда можно найти что-то новое в привычных вещах.

KA>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.

KA>ЗЫ: движок сайта в процессе разработки, так что ругайте господа, ругайте!

Статья на сайте посвящённая отладке, и то более познавательна... Вобщем ничего нового пока...

Здравствуйте, Kudinov Alexander, Вы писали:

KA>Может быть и реферат. К сожалению за 3 года проведения собеседований я выяснил, что 80% кандидатов на должность программиста С++ не знает этих азов.

KA>Я с удовольствием улучшу содержание статей, если критика будет более конструктивная. Что бы вы хотели видеть?

Галопом по европам. Все свалено в одну кучу. По охватываемому тобой материалу можно элементарно книгу написать страниц так на 400. "Debugging Applications for Microsoft .NET and Microsoft Windows" — толстенная книга, но там и то меньше тем затронуто. Сосредоточься на чем нибудь одном и опиши подробно. Полезность всех четырех статей с практической точки зрения стремится к нулю.

Ценность сомнительна , читать Code Complete макконела.

Здравствуйте, Kudinov Alexander, Вы писали:

KA>ЗЫ: движок сайта в процессе разработки, так что ругайте господа, ругайте!

s/&lt;/</g

Можете закидать меня камнями, но я не согласен с утверждениеми, что "Надо обязательно проверять все аргументы функции на корректность".
Корректность передаваемых парамеметров должен отслеживать вызывающий код. Возьмем пример, функция работающая с сортированным вектором,так чтоже теперь в теле функции проверять все элементы этотого вектора? Кроме того, такой подход делает код плохо читаемым и непереносимым.
Разработчик разрабатывает ту или иную функцию (метод) в соответствии с вариантами ее использования, соответственно и тестирование ведется
по вариантам использования. Если в методе есть баг, который никогда не всплывет, то это не баг (точно так же как new без delete не всегда означает утечку памяти). Мне кажется правильнее дисциплинированно подходить к написанию кода, а не полагаться на всякие отладочные примочки, тогда и код будет и надежнее и красивее. Если у системы грамотная архитектура, то ошибку в аргументах почти всегда можно выявить в течении нескольких минут. А кучи проверок, не дают нормально проанализировать код и выявить логические ошибки, которые гораздо опаснее. Я разрабатывал системы состоящие из сотни классов, и ни в одном методе небыло проверки аргументов и все прекрасно работало 24/7.
Все выше сказанное не относиться к библиотекам повторного использования.

Здравствуйте, Kudinov Alexander, Вы писали:

KA>Продвинутая отладка приложений

KA>Я немного систематизировал свой опыт разработки приложений, а точнее отладки. За годы работы я заметил, что правильная и эффективная отладка может существенно повысить качество приложений. Статьи, в которых я изложил свой опыт можно найти по адресу http://www.devdoc.ru/index.php/content/view/debugging_p1.htm

KA>Помимо отладки я освятил некоторые приемы по работе с отладчиком среды MS VS .Net 2003. Думаю, это будет полезно не только начинающим, но и гуру. Всегда можно найти что-то новое в привычных вещах.

KA>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.

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

От себя хочу добавить метод, который я думаю многим известен:

метод бинарного поиска по коду

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

Простой такой дедовский метод, но мне очень часто помогает.

Как народ относиться к подходу к разработке кода, обозначенному в subj? Разработка через тестирование всем знакома — использование unit-тестов, приемочный тестов и.т.п. Отладка для большинства — это дантов ад, бессонные ночи, workaround ы и.т.п. Возможно, причина в том, что отладка началась слишком поздно?

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

Приведу антитезы:
1. Код должен разрабатывать так, чтобы отладка не понадобилась. Идеальный код вообще не нуждается в отладке.
2. Поскольку идеальных кодеров нет, то придуманы тесты. Грамотно разработанные тесты позволяют находить ошибки без трассировки — и это гуд, поскольку трассировка отнимает слишком много времени. И в любом случае трассировка — это тупая работа.
3. Программа на отладку которой потрачено времени больше, чем на разработку — плохая, возможно стоит остановить бессмысленную работу по ее доведению до работоспособного состояния, провести рефакторинг или даже заново разработать отдельные части проекта.

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

Здравствуйте, Kudinov Alexander, Вы писали:

Век живи — век учись! (народная мудрость)
Мелочь, вроде бы, if (0 = value) { } а сколько времени экономит!!!

TarasCo wrote:
>
> Основные принципы я бы сформулировал так:
> 1. весь код должен хотя бы раз трассироваться вручную на этапе
> разработки, даже если он по мнению разработчика работает верно.
Не согласен, сильно зависит от кода и реализуемой функциональности.
> 3. дополнительный код, облегчающий трассировку и отладку полезен и ему
> нужно уделить максимальное внимание
Согласен.
>
> Приведу антитезы:
> 1. Код должен разрабатывать так, чтобы отладка не понадобилась.
> Идеальный код вообще не нуждается в отладке.
Теоретически, а практически идеальный код, как и идельный газ.
> 2. Поскольку идеальных кодеров нет, то придуманы тесты. Грамотно
> разработанные тесты позволяют находить ошибки без трассировки — и это
> гуд, поскольку трассировка отнимает слишком много времени. И в любом
> случае трассировка — это тупая работа.
Если UT не прошел, то чтобы исправить ошибку, часто без трассировки не
обойтись.
>
> Реальная жизнь всегда требует компромисов, но на мой взгляд первый
> подход к отладке и трассировке как минимум имеет право на жизнь .
В реальной жизни бывает так, что без отладчика я не всегда могу написать
работающий код — голова то не резиновая.
> Было
> бы интересно услышать доводы про и контра а также расширить и
> детализировать перечень тезисов.
Так что думаю, в зависимости от кучи причин нужно выбирать подход
совмещающий в себе и то и другое. Любые крайности сильно опасны и вредны.

Здравствуйте, Kudinov Alexander, Вы писали:
KA>Продвинутая отладка приложений
Смесь банальностей и, скажем мягко, вещей вводящих в заблуждение.
Умение ставить точки остановки -- продвинутая?
Ассерты (к слову, ASSERT и TRACE -- MFC-specific) тоже rocket science прямо из лабораторий Пентагона?

KA>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.
Прежде всего -- поправить русский язык: s/будите/будете/, разобраться с употреблением "-тся" и "-ться". Это самое бросающееся в глаза.
Про s/&lt;/</g уже тоже написали.

Ну и, непонятно зачем это вообще было написано. По степени раскрытия темы -- очень слабо, по каждому из затронутых вопросов можно было написать вдесятеро больше. По широте охвата тоже фигово: где compile-time assert'ы, где обзор способов прострелить себе ногу, где многопоточность, наконец? Упоминается стиль, но не упоминается о том, что его вообще можно (и нужно) стандартизировать, не говоря уж о ссылках на самые известные вещи типа "Industrial Strength C++". Кстати, о ссылках. Где они? Все это квинтессенция десятилетнего опыта, взятая прямо из головы? Не верю ! (c) Станиславский.

K>Простой такой дедовский метод, но мне очень часто помогает.


Отличный способ. Тусил вот тут на одном форуме, там буржуи, пользователи некоторого фрэймворка плачутся, что у них что-то падает, что-то не получается и т.п. У них интерпретатор С++, очень скверный — пропускает море ошибок и поощряет кривой способ программирования на С++ — сплошные new, указатели, все течет, грохается и т.п.
Вот у человека скрипт, его длина где-то пара сотен строк — это просто одна функиця . Я рекомендовал славный способ, описанный тобой, раз уж он просмотрев текст не видит свою ошибку (скрипт человек не показывает, секрет . Разработчики оплевали меня и посоветовали бедолаге ... юзать ВАЛГРИНД. Хорошо, он их не послушал, сам быстро нашел тривиальную "опечатку" (с поганым их интерпретером много какой байды проходит). А то бы потратил немало времени на чтение мануалов валгринда и чтение сообщений валгринда — а он много чего неприятного находит в самой библиотеке.

Здравствуйте, Lorenzo_LAMAS, Вы писали:

K>>Простой такой дедовский метод, но мне очень часто помогает.

L_L>
L_L>Отличный способ.

Ну так, фирма веников не вяжет


> Тусил вот тут на одном форуме[...]

У меня таких историй тоже много, помню текла память у меня, ну сидел с BoundsChecker'ом, маялся, чего то ничего не получалось, потом плюнул на это всё, начал просто комментировать куски кода пока не пропали утечки, потом начал раскомментировать пока не появились снова.В общем в течении часа нашёл источник утечек. В общем чо тут говорить — бинарный поиск — классика.

Здравствуйте, korzhik, Вы писали:

K>Здравствуйте, Lorenzo_LAMAS, Вы писали:

K>>>Простой такой дедовский метод, но мне очень часто помогает.

L_L>>
L_L>>Отличный способ.

K>Ну так, фирма веников не вяжет

>> Тусил вот тут на одном форуме[...]

K>У меня таких историй тоже много, помню текла память у меня, ну сидел с BoundsChecker'ом, маялся, чего то ничего не получалось, потом плюнул на это всё, начал просто комментировать куски кода пока не пропали утечки, потом начал раскомментировать пока не появились снова.В общем в течении часа нашёл источник утечек. В общем чо тут говорить — бинарный поиск — классика.

Мда.. Как говориться, кому лень читать манулы, тот просто "тыкает" пока не получиться . Есть другое название этому методу — "метод тыка" . Только это прокатывает в небольших проетах (аля нотэпада). А в серъезных проетах этот метод не поможет. А BoundsChecker и его потомок DevPartner — это то, чем нужно пользоваться. Один раз понять как и больше не будет желания комментировать.

Здравствуйте, korzhik, Вы писали:

K>УВ общем чо тут говорить — бинарный поиск — классика.

Главное — чтоб код был отсортирован

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Splin, Вы писали:

S>Мда.. Как говориться, кому лень читать манулы, тот просто "тыкает" пока не получиться . Есть другое название этому методу — "метод тыка" .

Нет, метод "тыка" это метод Монте-Карло, а я говорю о бинарном поиске


> Только это прокатывает в небольших проетах (аля нотэпада). А в серъезных проетах этот метод не поможет. А BoundsChecker и его потомок DevPartner — это то, чем нужно пользоваться. Один раз понять как и больше не будет желания комментировать.

Я умею пользоваться и BoundsChecker и DevPartner. И ещё я согласен с такой фразой "Никогда не говори никогда" В общем по ситуации надо смотреть.

Здравствуйте, Kudinov Alexander, Вы писали:

KA>Может быть и реферат. К сожалению за 3 года проведения собеседований я выяснил, что 80% кандидатов на должность программиста С++ не знает этих азов.

80% кандидатов не знают этой примиты? Эк вас угораздило. Где же такое нашествие чайников?

Здравствуйте, Splin, Вы писали:


S>А в серъезных проетах этот метод не поможет. А BoundsChecker и его потомок DevPartner — это то, чем нужно пользоваться.

Только вот он тормозит жутко на серьезных проектах.

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, Splin, Вы писали:


S>>А в серъезных проетах этот метод не поможет. А BoundsChecker и его потомок DevPartner — это то, чем нужно пользоваться.

AJD>Только вот он тормозит жутко на серьезных проектах.

На серъезных проектах должны быть серъезные компы . У меня на 2 Гб памяти и Core 2 Duo работать можно. Без инструментирования проверка на ошибки практически не влечет доп. тормозов.

Здравствуйте, TarasCo, Вы писали:

TC>2. Поскольку идеальных кодеров нет, то придуманы тесты. Грамотно разработанные тесты позволяют находить ошибки без трассировки — и это гуд, поскольку трассировка отнимает слишком много времени. И в любом случае трассировка — это тупая работа.

Что вы подразумеваете под трассировкой? Я считаю, что это снятие лога работы программы, и без этого часто не обойтись, если программа далеко от вас у юзера....

Здравствуйте, korzhik, Вы писали:

K>Здравствуйте, Splin, Вы писали:

S>>Мда.. Как говориться, кому лень читать манулы, тот просто "тыкает" пока не получиться . Есть другое название этому методу — "метод тыка" .

K>Нет, метод "тыка" это метод Монте-Карло, а я говорю о бинарном поиске


>> Только это прокатывает в небольших проетах (аля нотэпада). А в серъезных проетах этот метод не поможет. А BoundsChecker и его потомок DevPartner — это то, чем нужно пользоваться. Один раз понять как и больше не будет желания комментировать.

K>Я умею пользоваться и BoundsChecker и DevPartner. И ещё я согласен с такой фразой "Никогда не говори никогда" В общем по ситуации надо смотреть.

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

Здравствуйте, korzhik, Вы писали:

K>Ну так, фирма веников не вяжет

... а если и вяжет, то только фирменные!

Здравствуйте, Аноним, Вы писали:

А>Что вы подразумеваете под трассировкой? Я считаю, что это снятие лога работы программы, и без этого часто не обойтись, если программа далеко от вас у юзера....

Трассировка — это пошаговое выполнение программы.

Kudinov Alexander пишет:
> может существенно повысить качество приложений. Статьи, в которых я
> изложил свой опыт можно найти по адресу
> http://www.devdoc.ru/index.php/content/view/debugging_p1.htm

Хотелось бы порекомендовать автору верифицировать свою статью
в плане ошибок в языке русском.

На счет программизма согласен тоже.

эТО:

if(iValue == 0)
{
}

На языке С.С++ пишется вот так:

if( !iValue )
{
}

Здравствуйте, MasterZiv, Вы писали:

MZ>if(iValue == 0)
MZ>{
MZ>}

MZ>На языке С.С++ пишется вот так:

MZ>if( !iValue )
MZ>{
MZ>}

Нет, и еще раз нет! Судя по префиксу, это int, и не надо его использовать как булеан. Первый вариант прочитают все, второй — те кто точно помнит интовые значения true/false.

Здравствуйте, minorlogic, Вы писали:

M>Ценность сомнительна , читать Code Complete макконела.
Для начала Джона Робинсона, отладка приложения для Microsoft Windows, ценнейшая книга.
А статья конечно никакая.

Здравствуйте, Чили, Вы писали:

Ч>Здравствуйте, Kudinov Alexander, Вы писали:

Ч>Век живи — век учись! (народная мудрость)
Ч>Мелочь, вроде бы, if (0 = value) { } а сколько времени экономит!!!

Немного, если warning'и читать...

Здравствуйте, Alex Kirhenshtein, Вы писали:

AK>Здравствуйте, MasterZiv, Вы писали:

AK>

MZ>>if(iValue == 0)
MZ>>{
MZ>>}
AK>

MZ>>На языке С.С++ пишется вот так:

AK>

MZ>>if( !iValue )
MZ>>{
MZ>>}
AK>

AK>Нет, и еще раз нет! Судя по префиксу, это int, и не надо его использовать как булеан. Первый вариант прочитают все, второй — те кто точно помнит интовые значения true/false.

Кроме того второй вариант медленее, насколько я помню в msdn рекомендуют (expr)!=0, если тип expr не bool. Типа оптимизатор не будет оптимизировать, хотя я и не понял почему

Здравствуйте, Kudinov Alexander, Вы писали:

KA>Продвинутая отладка приложений

KA>Я немного систематизировал свой опыт разработки приложений, а точнее отладки. За годы работы я заметил, что правильная и эффективная отладка может существенно повысить качество приложений. Статьи, в которых я изложил свой опыт можно найти по адресу http://www.devdoc.ru/index.php/content/view/debugging_p1.htm

KA>Помимо отладки я освятил некоторые приемы по работе с отладчиком среды MS VS .Net 2003. Думаю, это будет полезно не только начинающим, но и гуру. Всегда можно найти что-то новое в привычных вещах.

KA>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.
Хочу, заметить одно обстоятельство с АПИ функциями IsBadReadPtr/IsBadWritePtr,
нет я не их противник, но и не их ярый сторонник
Просто, был один случай, когда на совершенно валидной памяти они выбрасывали ексепшн, насколько щас помни это был dirextx'ый surface, — пришлось assertvalid'ы на его указатели закомментировать..

Помойму, на codeproject'е по этому поводу есть хорошая статья, можно поискать.

Здравствуйте, Vain, Вы писали:

KA>>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.
V>Хочу, заметить одно обстоятельство с АПИ функциями IsBadReadPtr/IsBadWritePtr,
V>нет я не их противник, но и не их ярый сторонник
V>Просто, был один случай, когда на совершенно валидной памяти они выбрасывали ексепшн, насколько щас помни это был dirextx'ый surface, — пришлось assertvalid'ы на его указатели закомментировать..

интересная статья про IsBadPtr http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx

Здравствуйте, korzhik, Вы писали:

K>Здравствуйте, Vain, Вы писали:

KA>>>Пишите мне Ваши отзывы, вопросы и предложения. Наиболее интересные вещи я включу в статьи.
V>>Хочу, заметить одно обстоятельство с АПИ функциями IsBadReadPtr/IsBadWritePtr,
V>>нет я не их противник, но и не их ярый сторонник
V>>Просто, был один случай, когда на совершенно валидной памяти они выбрасывали ексепшн, насколько щас помни это был dirextx'ый surface, — пришлось assertvalid'ы на его указатели закомментировать..

K>интересная статья про IsBadPtr http://blogs.msdn.com/oldnewthing/archive/2006/09/27/773741.aspx
Помойму, та же статья где то также начинается

But this is a bad idea. IsBadWritePtr should really be called CrashProgramRandomly

Здравствуйте, Vain, Вы писали:
V>Хочу, заметить одно обстоятельство с АПИ функциями IsBadReadPtr/IsBadWritePtr,
V>нет я не их противник, но и не их ярый сторонник
V>Просто, был один случай, когда на совершенно валидной памяти они выбрасывали ексепшн, насколько щас помни это был dirextx'ый surface, — пришлось assertvalid'ы на его указатели закомментировать..
Это можно было бы и простить, если бы не одна вещь. Эти функции -- показывают погоду на марсе, а не валидность поинтера. То, что он читабелен еще не значит того, что он не смещен куда-то в сторону или на том месте уже давно не создан новый объект.

Здравствуйте, saproj, Вы писали:

S>80% кандидатов не знают этой примиты? Эк вас угораздило. Где же такое нашествие чайников?

Вам, видимо, везет. Увы, "чайников" на собеседованиях большинство. Некоторые по студенческой привычке пытаются списывать, давить кол-вом слов, выведывать вопросы и т.п., но любой шаг вглубь темы — и все, человек безбожно "плывет". Невозможно за ночь выучить то, что нарабатывается ежедневным опытом.

Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>Здравствуйте, Vain, Вы писали:
V>>Хочу, заметить одно обстоятельство с АПИ функциями IsBadReadPtr/IsBadWritePtr,
V>>нет я не их противник, но и не их ярый сторонник
V>>Просто, был один случай, когда на совершенно валидной памяти они выбрасывали ексепшн, насколько щас помни это был dirextx'ый surface, — пришлось assertvalid'ы на его указатели закомментировать..
EK>Это можно было бы и простить, если бы не одна вещь. Эти функции -- показывают погоду на марсе, а не валидность поинтера. То, что он читабелен еще не значит того, что он не смещен куда-то в сторону или на том месте уже давно не создан новый объект.
В microsoft'е похоже его юзают

Hi TarasCo

А>>Что вы подразумеваете под трассировкой? Я считаю, что это снятие лога работы программы, и без этого часто не обойтись, если программа далеко от вас у юзера....

T>Трассировка — это пошаговое выполнение программы.

Не всегда реально. Например мы пишем Application Server. Некоторые места принципиально нельзя пройти по шагам и добиться нужного результата (например проверить правильность синхронизации между потоками/подсистемами). Так же есть проблемы, чтобы пройтись по шагам на всем зверинце платформ (ну нету у нас HP-UX, а есть только у заказчика). Я уже даже забыл когда последний раз по шагам ходил, максимум лог просмотреть. А иногда и даже лог не доступен, остается только глазками. Сейчас даже не знаю зачем нужен проход по шагам.

--
С Уважением

Мда, по моему мнению статья слабовата и отдает бредом.

if(!iValue) — и больше никаких проблем
я так даже строки проверяю.

Верить или нет…
double *p, int size — не установишь размер программа просто сдохнет. все.


ASSERT(size &gt; 0); — не люблю проверять. не привык. писал большие программы, издевался над указателями, проверки только if. Эта сволочь приставала к моим окнам, просто ненавижу.
Хотя сейчас создаю массив, там буду использовать для контроля. там важна скорость и в релизе эти проверки не к чему.

Программы пишу:
1)мысль, что писать.
2)пишу
3)проверяю написанную часть
4)возвращаюсь к пункту 2.

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

Здравствуйте, s_viy, Вы писали:

_>Здравствуйте, Чили, Вы писали:

Ч>>Здравствуйте, Kudinov Alexander, Вы писали:

Ч>>Век живи — век учись! (народная мудрость)
Ч>>Мелочь, вроде бы, if (0 = value) { } а сколько времени экономит!!!

_>Немного, если warning'и читать...

Зато отлично похабит код! Нужно написать другую статью: Code Uglification Techniques. Туда войдут: Hungarian, if(0==value), (void)printf — для тех, кто любит указывать о явном опускании кода возврата, и другие дебильные приемчики, которые обожают некоторые программисты-недоучки

Здравствуйте, Splin, Вы писали:

S>Мда.. Как говориться, кому лень читать манулы, тот просто "тыкает" пока не получиться . Есть другое название этому методу — "метод тыка" .

Это не "метод тыка", а "метод научного тыка". Сечешь разницу?

Здравствуйте, alexeiz, Вы писали:

A>Зато отлично похабит код! Нужно написать другую статью: Code Uglification Techniques. Туда войдут: Hungarian, if(0==value), (void)printf — для тех, кто любит указывать о явном опускании кода возврата, и другие дебильные приемчики, которые обожают некоторые программисты-недоучки

Еще недопущение возврата из середины , в результате чего рождаются уродцы вида:

if ( bResult )
{
    // ...
    if ( somethingFailed ) bResult = false;
}

if ( bResult )
{
    // ...
    if ( somethingFailed ) bResult = false;
}

// ...

if ( bResult )
{
    // ...
    if ( somethingFailed ) bResult = false;
}
return bResult;

Здравствуйте, ambel-vlad, Вы писали:

AV>Не всегда реально

Естественно, я согласен . Точно также можно сказать про unit-тесты — есть куча случаев когда разработка через тестирование не эффективна или даже просто невозможна. Кроме того, сама идея разработки через тестирование проста и интуитивно очевидна. Тем не менее, на эту тему написано куча статей и книг, есть специальные средства для унифицированной работой unit-тестами. Основная идея моего поста, что отладчик можно использовать не только как средства поиска багов, но и как инструмент разработки и предлагалось обсудить, когда это будет эффективно, когда нет. Кстати, логирование — это также один из вариантов отладки по большому счету. Можно расширить мысль — программа должна трассироваться на этапе разработки, логи также должны вестись и анализироваться на этапе разработки — не только для поиска багов, но и для контроля качества. Допустим, я пол-дня чего то писал, реализовал некоторый функционал. Собрал, запустил — вроде все работает, сел писать дальше. Вот здесь нужно было протестировать качество работы. Каким образом: запустить тесты ( с этим понятно ), я предлагаю в качестве еще одного инструмента использовать трассировку ( или логирование ). В чем плюс — при внимательной трассировке или изучении лога можно обнаружить баг сделанный на предыдущих итерациях или увидеть несовершенство алгоритма. Особенно, если этим будет заниматься в стиле XP не тот человек, который писал код, так сказать, свежий глаз. Кстати говоря, в последнем случае трассировка может быть совмещена с code-review.

Hi TarasCo

AV>>Не всегда реально

T>Основная идея моего поста, что отладчик можно использовать не только как средства поиска багов, но и как инструмент разработки и предлагалось обсудить, когда это будет эффективно, когда нет.

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

T>Кстати, логирование — это также один из вариантов отладки по большому счету. Можно расширить мысль — программа должна трассироваться на этапе разработки, логи также должны вестись и анализироваться на этапе разработки — не только для поиска багов, но и для контроля качества. Допустим, я пол-дня чего то писал, реализовал некоторый функционал. Собрал, запустил — вроде все работает, сел писать дальше. Вот здесь нужно было протестировать качество работы. Каким образом: запустить тесты ( с этим понятно ), я предлагаю в качестве еще одного инструмента использовать трассировку ( или логирование ). В чем плюс — при внимательной трассировке или изучении лога можно обнаружить баг сделанный на предыдущих итерациях или увидеть несовершенство алгоритма.

При трассировке или логгировании вряд ли ты увидишь несовершенство. Тут как в старой русской поговорке. Слишком много низкоуровневых деталей перед глазами. Я вообще сторонник подхода при написании кода — день посидел и подумал, а потом за 5 минут написал. К такому подходу еще в школе приучил преподаватель информатики. Правда потом как-то увлекся использованием дебаггера. Но в последнем проекте (AppServer) нет возможности использовать дебаггер. А некоторые моменты даже логгированием нельзя проверить. Поэтому сначала много думаем, а потом мало пишем. И сравнивая свою производительность я увидел, что использование дебаггера только снижало производительность.

Все что описано, только личные наблюдения и мысли.

--
С Уважением

Здравствуйте, Splin, Вы писали:

S>Здравствуйте, korzhik, Вы писали:

K>>Здравствуйте, Lorenzo_LAMAS, Вы писали:

K>>>>Простой такой дедовский метод, но мне очень часто помогает.

L_L>>>
L_L>>>Отличный способ.

K>>Ну так, фирма веников не вяжет

>>> Тусил вот тут на одном форуме[...]

K>>У меня таких историй тоже много, помню текла память у меня, ну сидел с BoundsChecker'ом, маялся, чего то ничего не получалось, потом плюнул на это всё, начал просто комментировать куски кода пока не пропали утечки, потом начал раскомментировать пока не появились снова.В общем в течении часа нашёл источник утечек. В общем чо тут говорить — бинарный поиск — классика.

S>Мда.. Как говориться, кому лень читать манулы, тот просто "тыкает" пока не получиться . Есть другое название этому методу — "метод тыка" . Только это прокатывает в небольших проетах (аля нотэпада). А в серъезных проетах этот метод не поможет. А BoundsChecker и его потомок DevPartner — это то, чем нужно пользоваться. Один раз понять как и больше не будет желания комментировать.

На больших проектах BoundsChecker и его потомок DevPartner как раз и безполезены.
Баги в программе, помноженные на баги в DevPartner делают этот тул на больших проектах совсем бесполезным.

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

На данный момент, я исправил синтаксические ошибки. Над содержанием статей работа продолжается. Я учту все Ваши пожелания, и буду выставлять сюда новый материал для вашей оценки.

Я не ставлю перед собой цель написать исчерпывающее руководство по отладке или сделать из этого книгу. Поэтому материал не очень сильно систематизирован. Я буду подробней описывать те или иные моменты в следующих публикациях. Человека нельзя ничему научить, он может только сам захотеть. Я не буду все подробно разжевывать – кому надо тот приложит усилия, чтобы докопаться до сути. Я могу задать только направление. Мне приятно видеть, что некоторые участники форума открыли для себя что-то новое. Сейчас я просто стараюсь выдать то, что накопилось у меня в голове. Первые 4 части, которые я представил, это только начало. В планах писать об отладке COM, сервисов, DLL, DirectShow фильтров и т.п. Я буду считать свою задачу выполненной, если моя работа кому ни будь пригодиться. О чем бы Вам было интересно почитать?

Если у кого-то возникнет желание систематизировать весь материал и довести до ума – милости прошу. Пишите, обсудим.

PS: Я выложил еще одну статью про виртуальные списки на базе CListCtrl. Думаю, что новичками будет полезно. http://www.devdoc.ru/index.php/content/view/v_clistctrl.htm