Как раз Eclipse+CDT использую, правда больше в MSVC стиле и это никакого отношения к "сама консоль *sh с утилитами - эффективнейшая среда разработки" не имеет по сути. Самая эффективная работа с кодом происходит в IDE, консоль использую только для прогона тестов и некоторых нетривиальных операций с VCS.


Скрипты это хорошо, когда уже известно что именно в конкретном месте отладки нужно посмотреть, и то проще в окошко Watches добавить нужные выражения. А когда еще мало понятно в чем проблема и нужно по-быстрому посмотреть что же сейчас находится в структурах данных, то предлагается вместо удобных datatips в MSVC по шевелению мышки писать кучу скриптов для gdb?

Ну так это же не религия. Если нужно что-то, что проще делать в среде - можно воспользоваться средой.


А я наоборот. Но мне, как правило, и навигация по коду не нужна.


Откуда куча-то возьмется? Это одна-две строки.

Просто я наверняка что-то делаю не так, раз у меня большая часть получается проще в IDE, а не в "самой консоли *sh с утилитами - эффективнейшей среде разработки". В чем проявляется эффективность? Почти любые операции с кодом удобнее делать в среде, которая понимает семантику языка и помогает не сломать код своими изменениями.


Все связи между разными частями кода храните в голове? Проект небольшой и пишется в одиночку?


Ну так пересмотреть нужно много всего при отладке и раскрыть кучу вложенных структур данных. Там где в MSVC это будет просто подведение мышки к плюсику - в gdb отдельная команда (скрипт?), разве не так?

Думаю, что причин тому может быть две. Это активное использование ООП или большой размер отдельных функций/методов. Есть такое?


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


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

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

Приходится иногда работать с жутким легаси кодом на C, там ООП не используется, например. Много всего в глобальных переменных хранится, размеры функций часто за тысячу строк переваливают, виден копи-паст с мелкими изменениями. Как сквозь все это продираться без навигации по коду?


Это все в каком-то идеальном случае. А обычно бывает как-то так: пришел в новый проект, там код уже несколько лет пишется примерно десятком разработчиков. Какое-то проектирование и документация имеются, но они далеки от идеального состояния, часто описывают что-то уже устаревшее. Как по-быстрее разобраться в том куске кода, с которым приходится работать?


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

Лучше всего такое не писать.  А если уж написано, то заниматься рефакторингом.



Возможно. Тут я сравнивать не берусь, поскольку в такие ситуации практически ни разу не попадал.



Ну я не знаю, как это еще описать...

И я того же мнения, но никто на рефакторинг ресурсов выделять не будет. А вот интегрировать свои модули в этот продукт нужно и весьма тесно, поэтому нужно разбираться в коде и как это делать в "эффективнейшей среде разработки" без IDE я не представляю.



Т.е. всегда все очень хорошо спроектированно, все описано в документации, и она находится в актуальном состоянии? Когда нужно узнать где используется какой-то класс/структура/функция всегда можно быстро понять? Тогда вам очень повезло с проектами, я таких не встречал вообще. Не думаю что у вас общий случай и всем также повезло как вам.


Хорошо, тогда расскажите как можно быстро посмотреть значения в следующем простом случае:

В MSVC это просто несколько движений мышкой, даже кликать не нужно.

да ладно?! + вы не кликали разве?  


ЗЫ в Вашем случае структура класса простая, по этому все так приятно смотрится 

Фантом, Вас читаешь и страшно становится: навигация не нужна, ide не надо, ...   

Это сообщение отредактировал(а) chaos - 7.5.2013, 10:00

Как *nix-программист хочу порекомендовать тебе не осваивать - меньше конкуренции - больше денег. Как линуксоид рекомендую освоить - больше программистов, больше программ, больше пользователей. Не даром уже стим вышел на линукс. Я когда-то тоже начинал с Windows. Когда перешел на Linux то понял, на сколько Windows убог, если ты делаешь что-то нестандартное. А если у тебе необходима работа с оборудованием и задержки меньшие, чем 18 мс, то секса в винде будет на несколько порядков больше. Так как в *nix есть ожидание с точностью в наносекунды, а в винде это сделать можно только через цикл ожидания perfomance counters (другого решения я не нашел).

В целом у тебя очень слабое представление о мире *nix. Сравнивать FreeBSD (да и вообще любой "абстрактный" Linux) и Windows это тоже самое, что сравнивать рамный внедорожник и легковой автомобиль - едут оба, только во втором удобнее и девушку посадить не стыдно. В отличие от винды, у которой всего два основных варианта: desktop и server; никсы очень сильно дифференцированы по сферам применения: *bsd и debian - отличные серверные варианты, ubuntu и linuxmint - думаю, лучшие десктопные варианты, (Open)SUSE и Fedora/Red Hat - десктопы и серверы для корпоративных клиентов, Gentoo - любимый дистр растущих линуксоидов (на этапе между "чуть чуть знаю" и "использую везде"). Есть и другие: ArchLinux, Scientific и пр., но я их не пробовал. Я своего отца (более 60 лет) посадил на Linux Mint 13 Mate после винды. Показал как запустить наутилус и mc. С тех пор он пользуется и ни разу не звонил, чтобы узнать, как что-то сделать.

Если хочешь сравнивать, то поставь убунту или linuxmint (вариант mate рекомендую). Увидишь, что в сравнении с БСД это земля и небо - и видео играется, и документ пишется, и steam можно поставить, и пр. свистелки/перделки имеются. 

Давно не запускали отладчик в MSVC? Даже кликать не нужно, только подводить мышку!


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

Это сообщение отредактировал(а) kamre - 7.5.2013, 12:11

действительно!



ох уж этот юношеский максимализм   

Частенько линуксоиды gdb нахваливают, что мол все фичи есть и гораздо удобнее чем во всяких тормозных IDE. А вдруг правду говорят? 

Это сообщение отредактировал(а) kamre - 7.5.2013, 16:08

а необходимо везде и всегда!

чтобы тупо жать кнопки нужно подумать на какую из них нажать, их же не одна, или все же одна? И называется она "Волшебная палочка.  Думать не надо. Все, все, все сделает. Только также как двое из ларца одинаковых с лица, ну или наоборот же".

Тогда это несколько другая задача: не как сделать все правильно, а как сделать все быстро и дешево. Которая и в самом деле может иметь другое решение.


Если это не так, то начинать надо с приведения документации в актуальное состояние и т.п. А не латать дыры на скорую руку.


Вы можете написать то, что хотите посмотреть? Ну, например, для вывода соответствующего значения в файл? А что мешает в дебаггере написать то же самое и букву "p" спереди?


А Вы не пугайтесь. Это только первые лет двадцать страшно, а потом все проще.   

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


Проект развивается, продукт продается, и с более или менее нормальными IDE получается работать эффективнее с уже имеющимся кодом. На полное перепроектирование, переписывание и документирование с нуля всей системы никто не пойдет просто так из стремления к идеализму, чтобы в консоли и базовой поставке vim/emacs можно было также эффективно работать как в IDE.



Т.е. все ваши заявления про удобство отладки в консольном gdb были голословными и ничего продемонстрировать вы не в состоянии?