Что сейчас используют для разработки на с++?

vim

По непроверенной информации - qtcreator. Сложные конструкции выглядят по-разному.

Vim Сложные конструкции выглядят неприятно

Не слушай vim-emacs'еров. Этих укеракуков надо бы тереть с -7 наравне с перловскими однострочниками.

QtCreator можешь пощупать — довольно приятная вещь.

А в vs code для С++, такой же мощный отладчик как в vs studio?

Кукаретик здесь ты, а vim с youcompleteme + rtags хорош для C++ разработки. Дебагер нужен только чтобы посмотреть backtrace. Код надо учиться писать сразу правильно, но во время разработки допустимо использовать отладочную печать.

QtCreator. На vimохлам даже не смотри. Можешь попробовать хипстерский clion. Он фичастый, но платный и жрёт ресурсы как полоумный. Но от джабки другого можно было и не ждать.

Дебагер нужен только чтобы посмотреть backtrace.

Ага, именно.

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

Ну конечно...

Дебагер нужен только чтобы посмотреть backtrace.

Неосилятор отладчика на моё лоре. Куда катится мир.

Вимеры почти все такие: дело в том, что под vim нет хоть сколько-то юзабельного плагина для gdb.

Qt creator или же любая IDE/текстовый редактор, который поддерживает Language Server Protocol с Clangd

Кукаретик здесь ты

Дебагер нужен только чтобы посмотреть backtrace

Код надо учиться писать сразу правильно

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

Столько прекрасного в одном посте. Браво!

у гдб вполне себе нормальный собственный (cl|m)i, так что какие-то нужность каких-то вимо-емаксо-плагинов весьма сомнительна.

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

вполне себе нормальный собственный (cl|m)i

Это совсем не тот уровень комфорта, который предоставляет IDE.

и какой-такой комфорт (относительно того-же TUI gdb) представляют IDE, можно ли по-подробней?

Не шлангуй.
Как минимум в IDE ты просто пошагово бежишь по коду и сразу видишь значения всех интересных тебе переменных... Да, блин, АБСОЛЮТНО всё удобней, проще, быстрее и самое главное наглядней.

XXI век. Как-то даже неудобно объяснять всё убожество рантайм-отладки.

Как минимум в IDE ты просто пошагово бежишь по коду и сразу видишь значения всех интересных тебе переменных

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

Отладка в терминах языка С++. И еще можно внести изменение в текст и продолжить отладку с той же точки.

XXI век. Как-то даже неудобно объяснять всё убожество отладки через printf.

Поправил.

Ага, только сначала тебе нужно сообщить дебаггеру эти переменные. Их имена. В IDEeшке для этого не нужно ничего делать, ну или пару раз кликнуть мышкой. И шаблонная фигня в нормальной IDE будет выглядеть человекочитаемо.
Эх-х-х...
Слушай, я не пытаюсь тебя переубедить. Хоть чёртом лысым дебажь, только отстань от молодёжи со своими вимами-швимами.

Отладка в терминах языка С++

Это ещё что за зверь? :)

В IDE я могу сразу же ставить бряки и одной кнопкой запускать отладку. Пару мгновений и выполнение программы остановлено в нужном месте, есть стек вызовов и значения всех локальных переменных. Очень легко можно перемещаться по стеку вызовов и значения переменных так же будут подгружаться. Не надо вбивать в консоль имена функций или номера строк. Редактировать .gdbinit тоже не требуется.

Ещё чисто стилистические преимущества. У меня IDE настроена, как мне удобно: шрифты, размеры, подсветка синтаксиса, горячие клавиши.

У тебя в редакторе текст программы на С++ и вся отладка идет по этому тексту.

Хоть чёртом лысым дебажь, только отстань от молодёжи со своими вимами-швимами.

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

qtcreator неплох, но порой форматирование сходит с ума. Еще не очень радует интеграция с gdb.

У тебя в редакторе текст программы на С++ и вся отладка идет по этому тексту.

Круто! А шаблоны оно тоже отладит? И можно посмотреть, почему SFINAЕ зарубил перегрузку, например, или компилятор ушёл в рекурсию, компилируя?

Пока этого нет, никакой «отладки в терминах языка С++» тоже нет.

Еще разворачивалку макросов можно к этому списку добавить. Вообще ментальный дебаг это боль.

Отладчик для нубов. Лог/трейс и тесты наше всё. Читаешь чего делало ПО, смотришь, думаешь почему оно делало не так, как должно, пишешь тест который фиксирует этот кейс, делаешь его зелёным. Под хостовую архитектуру запускал отладчик ? раза в этом году, скорее всего 0.

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

Ну и termdebug в vim’e - таки торт. Интересно, будет ли ответочка от neovim?

разворачивалку макросов таки можно подсмотреть через опцию gcc `-E`, но кому захочется отлаживать получившееся месиво.. страшно представить :)

Так, стоп, а в каком уровне ты себя оцениваешь в сфере разработки ПО(начинающий, опытный, повелитель клито суньёр)? Если неофит, то да - vim/test/trace/test, таки наверное эребор. И лучше смотреть qtc/vscode и разбирать что же ты понаписал сначала в отладчике, пока плохо понимаешь и архитектуру и реализацию.

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

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

для разворачивания макросов, конечно.

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

Вот чем лучше нормальные логи - я могу сказать. Например без всякого rr (кстати в какой ide есть уже интеграция кроме этих emacs/vim?) можно понять что предшествовало неверному поведению и каковы его корни.

CLion норм. Отладка с шаблонами выглядит страшно. Если у тебя не сложная многопроцессная модель, то можно попробовать lldb вместо gdb.

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

А если программа использует boost? Что будет видно в отладчике?

Neovim + Deoplete + LSP

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

В общем я крайне рекомендую, если позволяют ресурсы начинать с тестов, на первых порах это будет в /dev/null, но это очень хорошая инвестиция.

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

Можешь посмотреть историю - я пару лет назад сам топил за qtcreator и ругал тех кто правит в vim’e что-то кроме конфигов, но, сначала обстоятельства вынудили, а потом я проникся таким подходом: тесты и логи. Багов в прод в таком варианте практически не попадает, и в 90% случаев это баги либо дизайна либо совместимости с окружением, даже скучно немного, ничего не падает, работает, все баги находишь либо в процессе разработки ты либо тестировщик на интеграционных тестах.

Не обязательно сразу прыгать в vim и подобные решения, просто постарайся держаться подальше от gui отладчика в тех частях, где у тебя есть знание того как устроенна реализация. А если и отлаживаешь - отлаживай тест а не всё приложение.

Ну и на сладкое - если ты имеешь хоть какой то опыт промышленной разработки, ты 100% уже писал и тесты и логи. Просто не оформлял как следует и не сохранял их. А сохранение обоих двух даёт недюжий прирост скорости при регрессионном тестировании и отладки сбоев на проде.

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

писать спец тест (интересно, если баг на стыке нескольких модулей монолитного приложения

Запросто, как впрочем и все регрессионные тесты

А что там с ней с границей модулей? Кто-то логи не умеет писать или тесты? Категории и мокапы наше всё.

Кто говорит про дебажить в уме, тут я ума не приложу… Дебажить не надо, читаешь отчёт - чего происходило и как менялся стейт. Смотришь с какой точки стейт пошёл меняться не так как задуманно. Даже в сорцы иногда можно не смотреть.

Я твой посыл - понимаю, и сам такое говорил возможно даже на этом форуме, всяким презренным любителям printf’ов. Ну, пока не переметнулся в их лагерь.

Нафиг все эти одноразовые котстыли и подпорки, steps to reproduce и скриншоты в треккере. Спека, тест, лог. Сетевой дамп или корка - раз в полгода когда ну совсем что-то из ряда вон и загадка загадок.

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

Ну вот к примеру (условный, но типичный кейс): есть баг «после захода в инструмент А, так что бы в процессе его работы кончилась память, если зайти в него второй раз и нажать Х, приложение падает», выясняется, что если в инструменте А кинулось исключение bad_alloc при определенной последовательности действий, статическая переменная Magic не обнуляет свое значение и при следующем заходе и нажатии на Х индекс в массиве выходит за границы. Как такое воспроизвести в написанном под это тесте (и на что его писать, без отладчика ты не знаешь где оно вообще падает) и как это отладить printf без применения отладчика?

Кстати, недавно мне сказали, что gdb умеет разворачивать макросы, причём, судя по документации, довольно толково.

Сейчас ты разозлишься, ибо ответ тебе покажется дебильным. В нормально инструментированной кодовой базе вероятности ошибок подобной этой - стремится к нулю. Да человеческий фактор никто не отменял, но, подобное A - словится нагрузочным тестом(коли уж исчерпание памяти это кейс, а оно станет кейсом при первом прецеденте), Б - как раз входит в категорию «раз в пол года» и попадёт в интеграционный регрессионый набор, возможно сразу для всех сущностей со сходным интерфейсом «инструмент А» :)

Тем не менее, если разработчик компонента «инструмент А» всё же писал и модульные тесты, то как минимум есть кейс для ситуации «заход и нажатие X» или более низкоуровневых примитивов из которых строится этот сценарий и дело за малым - поместить его в нужное окружение и наблюдать картину в частности а не во всём решении.

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

Кстати конкретно выход за границы потенциальный - и tidy найти может легко.

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

Итого для отладчика при определённым образом построенном процессе разработки остаётся не так уж и много сценариев:

• сбой там от чего у тебя нет сорцов
• баг в реализации компилятора, эмулятора или анализатора
• очень мощный и неумелый оверинжиниринг под допингом который прошёл ревью 31 декабря в 11-59 вечера и был залит несмотря на красный билд

Век живи. Огонь!

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