отладка C++ прог

>если в консольном попытаться ставить break на какие-либо ф-ции члены >классы - то он не находит их вовсе.

а можно пример? у меня все находит

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

Ъ

Я всегда использовал DDD. Да он страшненький, но можно привыкнуть и вполне эффективно использовать.

+1. Корки - наше все. )

>> Вопрос вот какой - кто чем пользуется для отладки C++ программ (особенно многотредовых).

В основном для отладки фарширую код printf'ами. Ещё использую встроенный в Eclipse/CDT фронтэнд к GDB. Иногда непосредственно GDB без всяких примочек.

>> Насколько я мог заметить у gdb с этим не очень хорошо обстоят дела - например, если в консольном попытаться ставить break на какие-либо ф-ции члены классы - то он не находит их вовсе.

Программа собрана с оптимизацией? Рекомендую отладочную версию собирать с -O0, иначе компилятор может переставить порядок разных операций в программе или вообще выкинуть какой-нибудь ненужный по его мнению код. Отладчик из-за этого ведёт себя очень странно и периодически ему сносит крышу 8).

Лично я чувствую тёмные места к коде как-то генетически, т.е., когда запускаю, уже знаю, что сейчас может случиться такой кошмар, что я даже не пойму, где упало.

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

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

Остальные пишут программы без ошибок?

> Остальные пишут программы без ошибок?

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

Отладчиком удобно глюки компилятора искать.

> отладчик нужен только индусам для отладки чужого кода который в первый раз видят. угу. а все не-индусы никогда не сталкиваются с кодом написанным кем-то другим. Они имеют диплом по велсипедостроению и потому делают все сами. Также не-индусы никогда не используют никаких библиотек, а те что используют подключают определив -D_YA_NE_INDUS после чего библиотеки всегда делают то что от них хотят :-))

> Отладчиком удобно глюки компилятора искать.

Неправда, хватает objdump -S :)

> написал своими кривыми ручонками

А мысль не возникла в твоей голове, что не обязательно своими?

в редких случаях - вставкой принтов и анализом корок.

в остальных случаев - пристальным рассматриванием кода...

valgrind, gdb

А с 1-4 гигабайтами кода написанного разными ручонками сталкиваться не приходилось? Сколько времени разглядывать пристально надо?

а сколько ты его в дебаггере разглядывать будешь?

>> А с 1-4 гигабайтами кода написанного разными ручонками сталкиваться не приходилось? Сколько времени разглядывать пристально надо?

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

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

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

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

Именно!!! Весь стек как на ладони. 
Более того, можно значительно более эффективно пойти по времени 
назад и найти место, которое приводит к ошибке,  
симитировать и проверить решение без пересборки.

Как раз недавно уволили любителя printf и аналогов.
Ну, не любил отладчик, а текстов слишком много 
"для пристального разглядывания" :-(

Таки printf, objdump хороши для первого десятка версий личного
софта, а дальше ...

Может вы просто не умеете пользоваться printf? А любителя printf уволили только за любовь к printf?

Ясно блин, что метод пофиг. Умеешь обойтись (хотя и printf иногда значительно меняет поведение тех же многосредных программ) - отлично.

Но превышение стандартного времени на типичную работу в 2-10 раз - перебор. Естественно уволили именно за это, а не за завления типа "отладчик только для идиотов". Но как факт оставшиеся умеют пользоваться отладчиком достаточно эффективно.

В принципе оптимально если средства отладки/тестирования являются частью системы. Любая активная форма отладки эффективнее обычного printf, хотя он и может входить в нее. Тем более, что при значительных объемах кода найти место, куда бы оный printf воткнуть является отдельной задачей. Дцать пересборок в день могут быть утомительны.

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

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

А если подключить дебагер только когда "интересная ситуация " уже возникла?

> Таки printf, objdump хороши для первого десятка версий личного софта, а дальше ...

Ну ядро в абсолютно подавляющем большинстве случаев на printk отлаживается. Ну через systemtap ещё, но это, практически, возможность внедрить printk в рантайме, без перекомпиляции, установки, ребута.

> А если подключить дебагер только когда "интересная ситуация " уже возникла?

Дебаггером, как правило, пользуются post mortem, когда софт на "интересной ситуации" завалился, и у тебя есть слепок жизни софта на момент падения. Циклы трассировать действительно смысла нет.