LINUX.ORG.RU

Опрос разработчиков C++: IDE vs Emacs + LSP (clangd)

 , , ,


1

2

Важно мнение разработчиков C++ (необязательно использующих Emacs) на тему:

какие возможности, хорошо реализованные в различных IDE для C++, отсутствуют (недостаточно полно реализованы) в Emacs.

Под «IDE» подразумеваются любые передовые среды разработки, в том числе не open source и работающие только на оффтопике, если они работают удаленно с таргетом линукс.

Под словом «отсутствуют» подразумевается, что для настройки или реализации этого функционала в Emacs будет недостаточно существующих пакетов и написания нескольких тривиальных функций втечение суток.

Критерии сравнения (уточните название IDE, чтобы я мог протестировать):

1 - отдельные возможности (features). Предполагаемый вариант ответа:

«Не использую Emacs, но вряд ли там можно сделать [feature_name] так, как можно сделать в [my_ide]».

2 - целый рабочий процесс (workflow). Предполагаемый вариант ответа:

«В Emacs будет непросто выполнить [цепочка действий, например, рефакторинг] таким образом, как можно выполнить в [my_ide]:»

  • - действие1
  • - действие2
  • - действие3

Цель вопроса?

Выделить разность по функционалу не в пользу Emacs, если есть. Особенно в свете развития LSP (например, clangd), с помощью которого индексация кода и построение различных связей между его элементами могут быть вынесены на отдельную машину. Т.е. ряд возможностей выносится за пределы средства разработки будь то Emacs, IDE, Vim и т.д. А значит возможности Emacs и IDE в этом плане уравниваются.



Последнее исправление: nasecom (всего исправлений: 3)
Ответ на: комментарий от AntonI

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

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

Т.е. код завершается нормально, ошибка в ответе воспроизводимая.

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

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

Так сколько итераций запусков на дорогущем кластере происходит до того как ты правильно подберёшь точки логирования?

Каюсь, мне нравится как у Вас пригорает от старой школы.

Послышался шелест перфокарт ))) Я видел среди коллег подобных тебе «дедов», которые тратили кучу времени на отладку своим «правильным» методом. Иногда я жалел их и за пять минут находил проблему богомерзким отладчиком. Но они продолжали трахать свои vim’ы c printf’ами. Всегда удивлялся этой закостенелости, поэтому и ворвался в эту тему. Ты хоть гитом пользуешься или по старинке засираешь шапку файла историей изменений?

Давайте подведем итог - как надо отлаживать Ваш же кейс

Я то свои баги закрываю быстро благодаря использованию современных инструментов. Мой кейс не про вычислительные кластеры. Но ты как-то резко соскочил со своего на мой. Не сливайся. После каждого твоего сообщения, я открываю всё новые грани твоей личности:

  • не знает про бряк по условию
  • не знает про остановку всех потоков
  • сразу билдит релизную сборку
  • отлаживает программу на кластере
  • не использует git ждём ответ
ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Послышался шелест перфокарт ))) Я видел среди коллег подобных тебе «дедов», которые тратили кучу времени на отладку своим «правильным» методом. Иногда я жалел их и за пять минут находил проблему богомерзким отладчиком. Но они продолжали трахать свои vim’ы c printf’ами. Всегда удивлялся этой закостенелости, поэтому и ворвался в эту тему. Ты хоть гитом пользуешься или по старинке засираешь шапку файла историей изменений?

Я не люблю влезать в чужие срачи, поэтому позволь мне прокомментировать только это. Я понимаю, что диды оставили в тебе неизгладимое впечатление, но представь на секунду, что мир не бинарен. Помимо состояний «отладчик» и «дебаг принтами» существует что-то еще, о чем тебе пытаются донести. И, если ты отбросишь свои предрассудки и попробуешь читать то, что тебе пишут, а не разговаривать с голосами в своей голове, ты можешь услышать другую точку зрения.

В конце концов, знание отладчика — это не то, чем можно хвастаться в 21 веке; это как сотрясать воздух, что ты слова в предложения складывать умеешь.

filosofia
()
Ответ на: комментарий от filosofia

Помимо состояний «отладчик» и «дебаг принтами» существует что-то еще

Конечно есть. При разработке - отладчик, на проде - логи.

В конце концов, знание отладчика — это не то, чем можно хвастаться в 21 веке

Согласен. Тем ужаснее предстают факты о людях, которые этот инструмент игнорируют.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Согласен. Тем ужаснее предстают факты о людях, которые этот инструмент игнорируют.

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

bugfixer ★★★★★
()
Ответ на: комментарий от Bad_ptr

Да я как то 20 лет без этого жил, но на тех у кого такое есть иногда смотрел с завистью…

AntonI ★★★★★
()
Ответ на: комментарий от bugfixer

У gdb ИМНО крутейшая фича это attach - когда все колом встало поглядеть где оно там висит и че делает. Вот это реально кучу времени экономит.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

У gdb ИМНО крутейшая фича это attach

Это то понятно. Но если хочется просто увидеть где именно оно крутится pstack обычно хватает, и так безопаснее. Ну или gcore и потом уже на корку gdb натравливать, offline так сказать. Тоже IMHO ;)

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от hobbit

Отвечу вопросом на вопрос - реализации clang под андроид бывают?

pon4ik ★★★★★
()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от AntonI

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

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

С кластерами - ответ простой, если не отлаживаться на проде, должен быть тестовый кластер с каналами для отладки. Но это конечно догоговато :)

В 99% случаев правильное логгирование лучшая отладка, для поиска проблем в логике, ничто кроме цены не мешает ему быть бинарным и эффективным в случае необходимости.

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

Если где-то отлаживают логику отладчиком а не тестами или логами, то скорее всего они крупно переплачивают(в том числе и своим специалистам).

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

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

Может есть какие то готовые решения? А то уже почти собрался велосипедить:-)

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Из «готовых» знаю только lttng, но на практике это как-то всегда был велосипед(не потому, что lttng плохой, а просто я перестал заниматься тем классом задач где нужно использовать высокочастотный трейсинг примерно в то же время когда узнал про lttng :)).

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Прикольно, спасибо.

Но я немного другое имел ввиду - есть ли фича, которая пишет в лог в бинарном виде занчения переменных, выражений и пр + утилита которая это потом парсит? Я так понял что lttng больше для трассировки и замеров производительности?

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

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

pon4ik ★★★★★
()
Ответ на: комментарий от AntonI

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

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Но готовых решений кроме lttng мне на глаза не попадалось.

Есть еще ebpf (на мой скромный взгляд самое перспективное средство), устаревший systemtap, тот же gdb можно использовать вместе с usdt probes, что-то еще было... Но да, lttng был единственным, что запустилось и работало как ожидалось, по степени готовности к употреблению lttng самый лучший был.

yetanother ★★
()
Ответ на: комментарий от AntonI

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

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

yetanother ★★
()
Последнее исправление: yetanother (всего исправлений: 1)
Ответ на: комментарий от ox55ff

Ядро без отладчика разрабатывается. Расскажи нам, пожалуйста, про продуктивность разработчиков ядра и Линуса лично :-)

anonymous
()
Ответ на: комментарий от anonymous

сам Линус

Зачем мне мнение человека, который не разрабатывает ядро? Менеджеры проектов могут что угодно думать.

6 Sep 2000

Свежачок.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Понятно. Ну ладно тогда, успехов в отладке ядра :-)

anonymous
()
Ответ на: комментарий от ox55ff

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

и открываешь ещё быстрее, благодаря использованию C++?

anonymous
()
Ответ на: комментарий от ox55ff

тяжко вам без рестартов живётся

anonymous
()
Ответ на: комментарий от AntonI

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

Сделал мой день =)

wandrien ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.