LINUX.ORG.RU

Идеальное IDE для C и C++

 , ,


0

3

Ребят, возник такой вот вопрос.

Для GNU/Linux (и не только) есть огромное количество IDE-шек со своими плюшками, перделками и т.д. Но у каждой из них есть свои недостатки, проблемы, баги.

В итоге, что для вас является важным при выборе того или иного инструмента для программирования на C и C++?

★★★

Последнее исправление: cetjs2 (всего исправлений: 2)
Ответ на: комментарий от emulek

Сразу видно человека с убеждениями:)

Ну эт пройдёт.

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

Можно мне этот же чеклист, с илюстрацией (хотя бы словесной)

1. Автодополнение и удобная навигация по коду (включая скорость работы этого дела). Без этого жить можно, но все становится медленее. Часто в больших проектах больше времени гуляешь по коду, чем пишешь. Ну и средства рефакторинга туда же - короче нормальный парсер кода.

давно уже рассказываю.

2. Интеграция с используемой билд-системой.

это которая http://en.wikipedia.org/wiki/GNU_build_system aka autotools ? А чего там «интегрировать»? Всё в текстовых файлах, формат распознаёт, подсвечивает. Для мелочёвки у меня хоткей на make повешен, в Makefile я прописываю hg ci, после каждого успешного билда(ага, Интеграция с DVCS!). там же вызов скрипта, который шифрует и бекапит коммит(ну то, что я наваял с момента прошлого соммита).

3. Интеграция и удобство использования отладчика.

я уже писал: долбёжка не для меня. Долблю редко, и из консоли. Но как-то поставил плагин ради интереса. Работает, долбит исправно.

4. Интеграция источников справки (man, qt, libstdc++ и т.п.).

м... там и интегрировать нечего, в короппке http://vimdoc.sourceforge.net/htmldoc/usr_12.html#12.6 надо в обратном направлении сделать, а то less задолбала

qt наверное тоже можно, вопрос: а нужно-ли?

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

Какое отношение здоровенные дампы mysql всё таки имеют к свойствам, превращающим vim в лучшее c++ ide?

ВНЕЗАПНО: SQL это тоже ЯП. И его тоже vim умеет. Так-то.

Даже как навигатор по файловой системе :)

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

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

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

веришь, нет? Я сейчас открыл какой-то свой cpp файл на 1000строк (у меня такие редкость), насчитал 7 вылетов за 80. Причём все эти места я хотел отрефакторить и/или доделать.

А причины просты:

1. много часов за монитором 80×25

2. мерж в DVCS, это когда на экране сразу три колонки кода, экран становится втрое меньше, и длинные строки врапяться.

3. читать строку 80 символов тупо неудобно, конец след. не найти.

Т.ч. правило грамотное.

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

Моё иде, даёт мне выбор:) Как минимум я могу им пользоваться а могу открыть за мгновение vim,

я не про то. Задачи поиска настолько разнообразны, а синтаксический C++ анализ так сложен(алсо и медлен), что быстрее не полагаться на встроенный в твою IDE супер-анализатор, а по быстрому накостылить регулярку.

И да, я всегда очень расстраиваюсь, когда что-то у меня имеет слишком большую область видимости. Потому поле поиска небольшое. А в чужом коде менять «kaka» на «pisja» не нужно.

Опять же, чего тебе покоя не даёт рефакторинг?

а кто начал про поиск/замену?

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

Любишь ты слово ВНЕЗАПНО, капсом ввернуть, однако, как бы внезапно оно не казалось SQL это язык запросов к системам рбд.

Консоль понятие очень растяжимое.

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

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

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

Задачи поиска настолько разнообразны, а синтаксический C++ анализ так сложен(алсо и медлен), что быстрее не полагаться на встроенный в твою IDE супер-анализатор, а по быстрому накостылить регулярку.

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

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

а кто начал про поиск/замену?

Вот только не надо путать тёплое с мягким.

Пока ты напишешь регулярку даже для encasulate field, которое не покрошит всё одноимённое, я тупо руками быстрее поправлю, если там меньше 100 целевых совпадений.

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

SQL это язык запросов к системам рбд.

я знаю. И его иногда надо править. С подсветкой и всеми делами.

Консоль понятие очень растяжимое.

короче как навигатор vim на любителя.

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

Угу, и того имеем поддержку одной, не самой свежей системы сборки

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

пару недопиленных плагинов

не правда. Я говорил про один, и то ненужный.

и кучу ручного труда.

ложь.

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

Конечно надо, но как это соотносится с крестовой иде - мне непонятно.

Ну изкоробочный на любителя, а задротское дерево, позволяет вполне прилично обозревать, большую, но аккуратно оформленную кодовую базу. Хотя лишней инфы всё равно больше чем нужно.

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

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

что, шаблоны и макросы тоже разворачивают? А ты знаешь, что программа

#include <iostream>

int main()
{
	std::cout << "hello\n";
	return 0;
}
разворачивается на 17000+ строк препроцессором?

И что, во ВСЁ это твои реализации нос суют?

не верю!

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

Аргументов нет, только злые факты...

Пошли неаргументированные обвинения во лжи и глупости, пойду и я вместе с ними.

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

Пока ты напишешь регулярку даже для encasulate field, которое не покрошит всё одноимённое, я тупо руками быстрее поправлю, если там меньше 100 целевых совпадений.

что-же это такое? Неужто вправду — засовывание паблик-поля под приват?

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

Угу, и общеизвестные принципы работы препроцессора вперемешку со станиславским, ха.

не верю!

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

нагуглил вот что:

class EncapsulationAndInformationHiding {
	private const int STATUS_ACTIVE = 0;
	private const int STATUS_HALTED = 1;
	private int status = STATUS_ACTIVE;
	private int getStatus() {
		return status;
	}
	public boolean isActive() {
		return getStatus() == STATUS_ACTIVE;
	}
 }

объясните тупому, на кой ляд делать private int getStatus(), а не просто вернуть STATUS_ACTIVE==status ???

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

В последний раз у меня появилось желание снова попробовать Eclipse+CDT, когда увидел, как человек скачал репозиторий llvm+clang, открыл или импортировал в эклипсе, и без бубнов и плясок там сразу работал Find Usages и прочая удобная навигация по коду, в то время как я пердолился с вимом, обвешанным костылями, мои команды GoToDefinition и GoToDeclaration глючили даже на моих собственных проектах а автодополнение YouCompleteMe было крайне паршивым.

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

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

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

Угу, потыкай в тот же qtc. Там парсер крестовый получше, плюс они clang based пилят, и 700к базу оно за ~три минуты парсит на i3 мобильном.

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

Я тыкал в QtCreator. Там парсер довольно паршивый (хуже, чем кланговский в YouCompleteMe) - многие фичи C++11 и C++14 не особо воспринимает. А так QtCreator довольно хорошая вещь, да, я в общем то либо вимом, либо им и пользуюсь. Но clang based пока что пилят ведь. Вот запилят до конца - тогда и можно будет о нем говорить.

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

Ну кстати, по дополнению, у меня к ycm вопросов нет, если всё сконфигурять по доке, оно норм пашет (правда надо конфигурять...). А вот GoToDefinitionElseDeclaration и иже с ним, работают как то через раз до сих пор.

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

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

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

Ну следует принять во внимание, что они считай свой шланг, запилили, во времена, когда его ещё в проекте не было :) Ну и в большинстве случаев его хватает. С комплитом, я видел баги только на std::* шаблонных тайпдефах.

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

Кстати шланговский бэк уже доступен, только отключен по умолчанию.

Ещё есть прикольные шоткаты аля C-Km<имя метода> найти во всём проекте методы с заданным именем, ну и такая же блажь для классов и прочих символов. Аля unite-vim, если пробовал. Файлы само собой там тоже поддерживаються. Кстати эту штуку они из идеи спионэрили.

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

не обижайся, но три твоих утверждений — это три правила демагога.

1. требовалось доказать наличие интеграции с системой сборки, я доказал на 1ом примере. Из чего ты сделал вывод, что ТОЛЬКО 1 система.

2. я говорил про один плагин, который мне не нужен, ты сказал про два, и откуда-то вывел, что плагин не допиленный.

3. ну и наконец про ручной труд вообще речи не было в том посте, но ты это откуда-то вычислил, да ещё и «горы».

а про тот код мне кто-нить другой расскажет ☺

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

Ну тут и вимовский интерфейс накладывает некоторые ограничения, надеюсь чуваки из neovim всё осилят.

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

ладно, я же не со зла. Всё равно дискуссия какбэ затухла.

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

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

pon4ik ★★★★★
()

qtcreator.

Жду допиливания CLion'а, у этих ребят плохих IDE не бывает! :)

Daeloce
()

Когда пишу новый код, то выбираю Sublime Text или Emacs. Когда приходится разбираться в чужом коде, то NetBeans.

Последний умеет кушать Makefile и более-менее умеет выдавать Usages для кода на С/C++. Плюс всегда можно посмотреть определение системных функций в исходных файлах по одну нажатию Ctrl+B, а затем тут же вернуться обратно по горячей клавише. Исходники posix в linux или исходники boost asio не вызывают эстетического удовлетворения, но часто дают массу полезной информации, нужной для дела.

В общем, все сообразно ситуации.

dave ★★★★★
()

В итоге, что для вас является важным при выборе того или иного инструмента для программирования на C и C++?

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


  • QtCreator быстрый, легкий, но его индексер довольно посредственный, а уж UI вообще неудобен.
  • Eclipse имеет лучший индексер из всего, что я видел. Но на этом его плюсы кончаются. Тяжелый и неповоротливый, даже вкладки в UI переключаются с заметными лагами. Не индексирует незнакомые ему заголовочные файлы без расширения, пока не задаешь ему их вручную (что очень мешает работе с Qt). Имеет постоянные проблемы с анализом вывода компилятора: то игнорирует -isystem пути, то еще что-нибудь. Но в принципе при должном упорстве почти все эти проблемы можно побороть с помощью костылей.
  • KDevelop вроде бы то, что нужно, только разработчики упоролись своей ЛГБТ-подсветкой. Я не против такого варианта, если бы был режим расширенной подсветки для обычных людей. Но нет - либо радужный венигрет, либо простейшая синтаксическая подсветка из KPart.
  • CodeBlocks - давно его не щупал, вроде бы много чего умеет, а с другой стороны постоянно был чем-то неудобен. Использует WxWidgets, поэтому страшен в плане UI.
  • CLion - перспективная IDE, которая находится сейчас в разработке. В настоящий момент имеет массу проблем. Такое ощущение, что до работы над ним разработчики не сталкивались с CMake вообще и поэтому сейчас они старательно придумывают непонятные ограничения. Сборка проектов производится только глубоко внутри ~/.clion10/ директории, нет возможности выполнить простейший make all (CLion вытаскивает имена целей из CMakeLists.txt и позволяет собрать только конкретную цель), индексер делает кучу ошибок и даже текстовый редактор сильно тормозит при вводе текста в проектах чуть серьезнее hello world. Надеюсь разработчики поправят весь этот ужас, потому что сейчас этим IDE пользовать чуть более чем нереально.
m0rph ★★★★★
()
Ответ на: комментарий от itn

cat

Острый глаз и намагниченная игла.

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

нифига себе немного, я так нормально и не настроил себе его.

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

QtCreator быстрый, легкий, но его индексер довольно посредственный, а уж UI вообще неудобен.

Пробовали использовать Clang плагин?

Вот мое личное мнение по этому поводу


  • QtCreator
    Pros: кросс-платформенность, Emacs mode, VIM mode, поддержка valgrind, темная тема (опц.), поддержка Clang в качестве анализатора, поддержка всех популярных систем контроля версий

    Cons: недостаточная поддержка CMake. Например, нельзя «налету» переключиться между Debug и Release. Раздражает баг, когда после переключения раскладки надо нажать кнопку два раза, чтобы напечатать первый символ. Рефракторинг на зачаточном уровне
    Также, почему-то не видит некоторые includes (у меня не видит QtTest - поэтому иногда переключаюсь на CLion)
  • Microsoft® Visual Studio™
    Pros: хороший анализатор кода; CodeLens (позволяет просматривать историю изменений кода у каждой отдельной функции согласно VCS)

    Cons: режим Emacs не позволяет копипастить код из других приложений (даже с помощью ReSharper). Не хватает некоторых базовых вещей (например, рефракторинга), для которых нужно покупать расширения: VAX или ReSharper. Windows only. Из коробки поддерживает только TFS и Git, но это исправляемо расширениями. Поддержка CMake через расширение

  • KDevelop: нет режима Emacs; нет темной темы для IDE (а не только для редактора). Поэтому особо не смотрел (но, кстати, судя по всему, режим Vi там лучший из всех)

  • CLion: по мне норм. Наилучший режим Emacs из представленных, Darkula, поддержка CMake на уровне, индексирует все include, поддержка VCS тоже на уровне/ Не понимает пока некоторых новинок C++11/14 и тормозит. Но на моем железе это незаметно, фатальных недостатков нет.

    Cons: единственная платная IDE без бесплатного варианта (сейчас EAP, потом бесплатного варианта не будет); кроме CMake ничего не поддерживает
pashazz ★★★★
()
Последнее исправление: pashazz (всего исправлений: 1)
Ответ на: комментарий от pashazz

Eclipse не торт, потому что Workspace и темной темы нет

Темные темы не нужны, но они есть для Eclipse.

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