IDE для C/C++ для проектов со сложными билдсистемами

Если уж брать IDE «общего назначения», то CLion.

Разбудите меня, когда он не будет жрать 8 гигов оперативной памяти и не будет тормозить на каком-нибудь старом core 2 duo (что и так очень много для задач редактирования кода).

и так очень много для задач редактирования кода

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

а что насчёт того, что поиск/редактирование регэкспами в этих ide вешает их на некоторое время выжирая одно ядро.

И это тоже, да. Обычный grep ищет существенно быстрее всяких там платных проприетарных IDE на жабе.

А ripgrep на Rust’е ищет ещё быстрее, чем grep.

Это был вопрос «с подвохом» (:

Есть такие IDE?

По хорошему - это не дело как бы самой IDE парсить исходники и прочее дело. По хорошему - это сама билд система должна предоставлять IDE всю необходимую инфу о списке файлов, дефайнах и прочее..

Я, к примеру, знаю очень хорошую связку - это связка билд системы QBS и таких IDE-шек как QtCreator и VSCode.

Там QBS работает в режиме сессии отдельным процессом и взаимодействует с IDE через межпроцессные собщения, посредством специального JSON подобного протокола. В этом случае сам QBS предоставляет полную инфу о проекте который он компиляет посредством запроса спец. командами. Также оно предоставляет инфу о пред-определенных макросах тулчейна, о его инклюдах и прочее..

Т.о. IDE знает все о проекте и подсвечивает все что надо для любых тулчейнов, поддерживаемых QBS (а он поддерживает дохрена чего).

Благодаря такому подходу оч. легко интегрировать QBS с любой IDE (описание протокола не сложное).

PS: Все уже придумано до нас. Но непонятно, почему люди жрут кактусы в виде всяких Make, CMake, Meson и прочих. ;)

$ export CC=log-cc-and-generate-project-sln.sh $ build

Остальное навесишь по вкусу, проблем просто нету.

Именно! Сам хотел написать. Приблизительно так делают статические анализаторы типа Sonar, Coverity чтобы не зависеть от билд системы и вытягивать все параметры компиляции. Правда у всех них это сделано через wrapper утилиту, а не через только переопределние СС.

Для таких как ты есть vim. А тут про IDE речь. Лучше CLion IDE для C/C++ нет.

Воткни ещё плашку, память дешёвая ©

Мммм? Уже есть альтернативы?

Кста - CMake тоже так научили делать.

Сложные быдлосистемы не нужны.

Да, выстраданные IDE-специфик реализации.

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

А можешь пример функционала связанного с кодом выдать который нигде не реализован с помощью LSP?

В новых версиях 12.x плагин никак не доделают

У меня он идёт с самой средой NetBeans 12.4, развёрнутой из ZIP-архива с сайта Apache. Ничего доустанавливать не надо.

Если бы он не работал, как бы тогда проекты с JNI собирались?

Могу, LS раста фактически мёртв и не реализовывает ничего)

И что, прям для любых тулчейнов (тех что кроме GCC, CLang и MSVC)? Не прошло и 100 лет, хотя и не верю.

Вообще, я всерьёз не разбирался в кишках LSP, но следующее выглядит не его заботой:

• сгенерировать шаблоны новых файлов, геттеры/сеттеры
• найти все имплементации интерфейса / переопределения метода
• заниматься всем, что касается отладки
• проверять «встраиваемый» код - подсвечивать ошибки в SQL/JPQL запросах в строках, чекать включения HTML в JS, работать с автокомплитом подобного
• фреймворк-специфик фичи - ругаться на дублирование @GeneratedValue в отображённой на БД сущности, проблемы в persistence.xml и прочие межфайловые взаимоотношения в проекте, а также генерировать шаблонный код и автокомплитить
• etc

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

QtCreator. Поддерживает не только make проекты как тут пишут, а в принципе любые (даже извращенно кастомные). И, в отличие от всяких недоредакторов не требует записи билд плана для определения того, какие файлы входят в проект (как здорово это говно НЕ работает, когда билдишь под разные архитектуры).

Скрин текущего проекта: https://i.postimg.cc/wTzywvqx/2021-07-06-12-46-57.png

сгенерировать шаблоны новых файлов, геттеры/сеттеры

это вроде code actions покрывают, хотя я не оч. пользовался даже в IDE

найти все имплементации интерфейса / переопределения метода

это покрывается на уровне find references/declarations/implementations тем что есть возможность вернуть список вариантов например

заниматься всем, что касается отладки

это да, для этого есть другие протоколы, в том числе и тот который в VSCode представлен, но такого развития как LSP он не получил

проверять «встраиваемый» код - подсвечивать ошибки в SQL/JPQL запросах в строках, чекать включения HTML в JS, работать с автокомплитом подобного

это есть на уровне всяких fixits и собственно комплита

фреймворк-специфик фичи - ругаться на дублирование @GeneratedValue в отображённой на БД сущности, проблемы в persistence.xml и прочие межфайловые взаимоотношения в проекте, а также генерировать шаблонный код и автокомплитить

это есть опять же на уровне fixits и code actions. Даже semantic higlhight есть, только не помню вышло ли оно из статуса нестандартных расширений протокола.

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

Там скорее всего сам по-себе функционал беднее, чем в QBS но детально я не разбирался, почитай про cmake-server.

Лучше CLion IDE для C/C++ нет.

Да для меня даже какой-нибудь Code::Blocks получше будет т.к. не тупит на ровном месте и не написан на жабе.

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

Ты бы ещё к notepad.exe прикручивал, сетевые бобы всегда меня разочаровывали.

Всегда умело. Более того ЕМНИП это единственная ide-шка где можно из коробки на другой машине настроить сборку проекта и его запуск.

the silver searcher (почти?) такой же быстрый как ripgrep, и не нужны никакие расты)

Что забавно, пшик вышел по вине RLS. Линтер так и не удалось заставить работать.

Я бы такие вещи проверял минимум в двух клиентах. Вроде растовый серверок один из самых фичастых на самом деле так-то, и если емаксеры с виммерами не плачут, то видимо дело не в сервере а именно в реализации клиента.

VSCode это конечно не IDE, но там эту идею (запуск и сборка проекта удалённо) развита очень и очень интересно. В случае vsc там же и анализ кода производится например.

RLS вполне может быть подзаброшен, т.к. все давно переключились на rust-analyzer.

Я под ядро пишу в QtCreator’е, используя generic project.

У него более-менее сносный анализ кода на основе clang, единственное, спотыкается на некоторых gcc-специфичных макросах в ядре.

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