Комментарии 64
Ну для начинающего программиста я бы посоветовал не gdb а NetBeans. Отладка нам намного удобнее чем голый gbd
Правда очень не хватает просмотра стека
насчет удобства я бы поспорил. я, перепробовав почти все, вернулся к выводу, что gdb практически идеален для C/C++. никакой другой отладчик не позволяет с такой скоростью и гибкостью отлаживать программы любой сложности.
и да, кстате, нам когда-то в университете преподавали программирование, все было под линукс, первый курс — nasm, второй C/C++. отладка в обоих случаях в gdb, редактировать учили в vim'е. ничего, студенты без проблем и стрессов осваивали это все. сложность для начинающих весьма преувеличена
А мы редактировали в vi :)
НЛО прилетело и опубликовало эту надпись здесь
Wolong, на комментарий которого вы отвечаете, писал про Vim. Vim, в отличие от vi (а также pico и nano) умеет подсветку синтаксиса, автодополнение и навигацию по коду. Порог вхождения высокий, но как редактор для программиста он очень хорош (опять же в отличие от pico и nano).
НЛО прилетело и опубликовало эту надпись здесь
На vimeo один хороший человек наклепал кучу полезных скринкастов. А на хабре есть соответствующий блог хаб.
НЛО прилетело и опубликовало эту надпись здесь
Чтобы он потратил весь запал на то, чтобы разобраться в IDE? Лучше что-то простое
Хотите сказать в gdb не надо разбираться? В IDE я нажал Debug и сразу увидел все на одном экране — переменные, память, ассемблерный код с кодом С++ для удобства отладки
Хочу сказать, что Netbeans слишком сложен и монструозен для новичков и не только.
Ну это вы знаете, это чисто Ваше мнение. Для меня наоборот, так как я программировал в нетбинсе под джаву было все очень понятно. У каждого свой опыт за плечами и свои вкусы. Я просто решил что так как статья для новичков в С, то не помешает упомянуть альтернативный способ. Пусть люди выбирают, я ничего не навязываю же
kdevelop/eclipse
в первом дебагер по проще, во втором по информативнее, но оба используют gdb.
в первом дебагер по проще, во втором по информативнее, но оба используют gdb.
Не всегда есть выбор, у меня, например, не было.
в чем смысл статьи? упомянуть названия инструментов? насчет coredump — в той же убунту для его создания необходимо поставить пакет linux-crashdump. Когда «рисуются вопросики», ломается стек, куча, и происходит прочее волшебство, связанное и повреждением памяти, куда лучше поможет valgrind, разберет с указанием строк кода, что не так, как и почему.
> strace (монитор системных вызовов)
и ltrace(1).
и ltrace(1).
> … или что делать если «Hello world!» упала
Купить расческу для рук. Сменить компьютер. Не запускать «Hello world!». :)
Купить расческу для рук. Сменить компьютер. Не запускать «Hello world!». :)
НЛО прилетело и опубликовало эту надпись здесь
Нет, друзья, нет нет и еще раз нет системе контроля версий для начинающего программиста!
Надо писать много, много и дико, и желательно с одного раза, с одной попытки на упражнение\задание\пример! А контроль версий тут только задержит!
Надо писать много, много и дико, и желательно с одного раза, с одной попытки на упражнение\задание\пример! А контроль версий тут только задержит!
У меня была проблема когда начал изучать Си/Си++/Windows/MSVC6 — неосторожное изменение кода влекло за собой падающий проект. Я начинал комментировать код, пытаясь понять что именно падает и как сделать так чтобы не падало. Позже я научился делать частые бэкапы в другую папку с указанием даты. Если бы мне тогда показали на контроль версий — да я бы был счастлив.
Мне очень отладчик ddd нравится. Это GUI над gbd, внизу можно в консоль писать команды gdb, но так же есть гуи. Выглядит правда жутко (интерфейс какой-то очень нативный и древний), но дело свое успешно выполняет.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, круто. Попробую. А шорткаты-то есть? Типа перейти до следующего брейкпоинта, войти в метод. Или все через «консоль»?
НЛО прилетело и опубликовало эту надпись здесь
Многие команды gdb можно сокращать до одного символа:
Запустить программу: run или r
Шаг вперёд: next или n
Войти в функцию: step или s
Поставить новый breakpoint: break или b
«Отпустить» выполнение до следующего breakpoint-а: continue или c
Иногда до двух-трёх символов:
Отключить breakpoint 3: disable 3 или dis 3
Включить breakpoint 3 обратно: enable 3 или en 3
Выполнять код до строчки 123: advance 123 или adv 123
Выполнять код до конца функции: finish или fin
Конечно, не совсем шорткаты, но почти.
Запустить программу: run или r
Шаг вперёд: next или n
Войти в функцию: step или s
Поставить новый breakpoint: break или b
«Отпустить» выполнение до следующего breakpoint-а: continue или c
Иногда до двух-трёх символов:
Отключить breakpoint 3: disable 3 или dis 3
Включить breakpoint 3 обратно: enable 3 или en 3
Выполнять код до строчки 123: advance 123 или adv 123
Выполнять код до конца функции: finish или fin
Конечно, не совсем шорткаты, но почти.
Или из «обычного» gdb — layout src, layout split, или лучше help layout :)
-tui колбасит от utf-8 комментов в коде :-( я юзаю cgdb
Также можно запускать переключаться между обычной командной строкой и TUI c с помощью «Ctrl-X A» или «Ctrl-X Ctrl-A», т.е. не важно, когда вы отжали Ctrl после Ctrl-X.
Так же можно посоветовать memwatch для отслеживания утечек памяти. Лично мне очень помогает.
А я привык отлаживаться с помощью printf. Кидаю в лог кучу всего (метки прохождения участков кода, значения переменных). Запускаю и смотрю вывод, анализирую. Привычка выработалась в результате отсутствия пошаговых отладчиков под некоторые платформы. В случае реалтайма возникают сложности. В худшем случае приходится выводить сигналы на выводы микроконтроллера и смотреть осциллографом. (например, в начале исполнения участка кода устанавливем вывод в единичку, в конце исполнения выставляем в нолик. запускаем и смотрим осциллографом. Думаем.)
Если же отладчик под текущую платформу присутствует, всё равно не использую. Привычка.
Если же отладчик под текущую платформу присутствует, всё равно не использую. Привычка.
О боже, как это похоже на разработку под PHP. Даже если есть куча нормальных средств, от привычки использовать var_dump отказаться очень сложно :( Да и редко бывает нужно, вообще говоря
Да, я тоже не люблю все эти самолеты и позда — от привычки ходить пешком отказаться очень сложно :( Да и редко бывает нужно, вообще говоря.
Вполне хватает случаев, когда логгирование даёт намного больше пользы, чем отладка.
Как я вас понимаю. Я тоже от дома в продуктовый магазин хожу пешком. Каждую неделю трачу десять минут, чтобы туда дойти, а ведь давно бы уже пора туда самолётом летать.
Когда 10 минут (отладочный вывод) это одно. А когда серьезный дебаггинг, напихивать 100500 принтфов, чтобы потом их удалить или закомментить (ибо слишком много мусора в логах после отладки) это двойная работа: сначала сделать из 3-х строчной функции 10 строчную (образно), а потом или отключать это ифа-ми или комментировать/удалять.
Отладчики как раз для решения это проблемы и придуманы, как и, допустим, исключения — чтобы не засорять чистый код неосновными вещами.
Отладчики как раз для решения это проблемы и придуманы, как и, допустим, исключения — чтобы не засорять чистый код неосновными вещами.
И ведь что характерно так и есть, без сарказма))
Я в детстве, еще в Турбо Си, пошагово трассировал с слежением за переменными через watch. Этот метод чтоль уже не рулит?
Забыли упомянуть, чтобы GDB нашел нормальную отладочную информацию, неплохо бы дать флаг -g при сборке и выключить все оптимизации.
Все-таки более традиционным уже считается «многопоточность», а не «многонитевость».
К примеру, для программистов WinAPI существуют потоки (threads) и нити (fibers) и это устоявшийся и официальный перевод.
К примеру, для программистов WinAPI существуют потоки (threads) и нити (fibers) и это устоявшийся и официальный перевод.
То для программистов WinAPI. А для программистов С++ существуют потоки (streams) и нити (threads). Трудности перевода в общем. Я в таких случаях вообще стараюсь английскую кальку использовать, хоть это и коряво звучит, чтобы не было неоднозначностей.
Приведите, пожалуйста, контекст (а лучше фразу/предложение) в котором можно спутать «поток» в значении «поток ввода/вывода == stream» и «поток» в значении «поток исполнения == thread».
А «fiber» обычно переводят как «волокно» или «пользовательский поток»
А «fiber» обычно переводят как «волокно» или «пользовательский поток»
В контексте то как раз в большинстве случаев понятно о чем речь. Просто чтобы одним словом не называть две кардинально разные сущности некоторые называют стримы потоками, а треды нитями. А файберы волокнами, да.
Ну а если есть устоявшиеся в книгах переводы, и вам из контекста все понятно — зачем этим коверканьем заниматься?
Ну когда один поток пишет в поток, а другой поток из этого потока читает — то всё ж понятно из контекста? Но звучит не очень.
Вообще спор из серии «Называть долину силиконовой или кремниевой». Вроде всем понятно, что кремниевой, но устоявшееся название и всё такое… В итоге используются оба.
Вообще спор из серии «Называть долину силиконовой или кремниевой». Вроде всем понятно, что кремниевой, но устоявшееся название и всё такое… В итоге используются оба.
Найти бы того, кто их устоял в своё время…
Как могло придти в голову перевести «thread» как «поток» — не представляю.
Как могло придти в голову перевести «thread» как «поток» — не представляю.
Не важно кому пришло это в голову. Это термин. Он в книгах, переводах. Хороших и рекомендованных. Терминология существует не для того, чтобы ухо радовать (хотя это, бесспорно, ее приятное свойство), а для того, чтобы можно было обмениваться информацией, не переобозначая каждый раз, определения используемых слов
ulimit -c unlimited для core-файлов любого размера. Иначе по обрезку мало потом чего скажешь.
НЛО прилетело и опубликовало эту надпись здесь
Я учил gdb по этой доке www.opennet.ru/docs/RUS/gdb/
Вообще самая лучшая подборка документации на русском на опеннете.
Вообще самая лучшая подборка документации на русском на опеннете.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Отладка программ на C для начинающих