Комментарии 59
Спасибо за статью.
Было бы хорошо более полно расписать каждый редактор. К тому же я думаю стоит добавить в этот список Qt Creator и QDevelop\Kdevelop.
Было бы хорошо более полно расписать каждый редактор. К тому же я думаю стоит добавить в этот список Qt Creator и QDevelop\Kdevelop.
QDevelop RIP.
Kdevelop нормальная среда, но я в ней работал 5 лет назад…
Сейчас работаю Submile как текстовым редактором… а если что поддебажить на продакшене то — vim.
Сейчас работаю Submile как текстовым редактором… а если что поддебажить на продакшене то — vim.
Советую вновь обратить свой взор на KDevelop. Четвертая версия не сравнима ни с чем. Скажем, я ее не променяю ни на что.
Я не говорю что вы прям обратно броситесь, но как минимум попробовать что да как очень советую. Особенно если ваша работа связана с большим количеством разрозненных исходников, которые сложно собирать, но нужно редактировать.
Я не говорю что вы прям обратно броситесь, но как минимум попробовать что да как очень советую. Особенно если ваша работа связана с большим количеством разрозненных исходников, которые сложно собирать, но нужно редактировать.
Про Qt Creator забыли
Требует установку;
Почему это минус? Как для кого…
Я тоже считаю что kdevelop хорош, но как уже по-моему было сказано выше, каждый выбирает что ему удобнее :)
Перепробовал их все в свое время. Дольше всего задержался на Code::Blocks. А потом перешел на Вим и назад не тянят.
Единственное, чего не хватает — это дебаггера уровня Visual Studio. К сожелению, все вышеперечисленные IDE используют в качестве бэкенда GDB, который просто морально устарел. В этом плане Visual Studio на сегодня вне конкуренции, и врядли когда-то будет.
Единственное, чего не хватает — это дебаггера уровня Visual Studio. К сожелению, все вышеперечисленные IDE используют в качестве бэкенда GDB, который просто морально устарел. В этом плане Visual Studio на сегодня вне конкуренции, и врядли когда-то будет.
Уточните, чем это GDB морально устарел.
> и врядли когда-то будет.
Слышали ли вы про LLDB?
> и врядли когда-то будет.
Слышали ли вы про LLDB?
Студия вообще-то использует CDB, который весьма аналогичен.
А? gdb это самый мощный отладчик, с которым мне доводилось работать. Да, он не такой и красивый и наглядный как отладчик в VC++ но в плане возможностей, гибкости и автоматизации, он на много впереди его. Просто для примера, для одного проекта для gdb парочкой несложных скриптов добавили полную поддержку «green threads», которые использовались в приложении, включая стеки, статусы и все остальное. Что называется, удачи попробовать повторить это в VC++ :)
> средство разработки специально для C и C++. Оно не кроссплатформенное, но отлично интегрируется со средой GNOME, а соответственно с Ubuntu.
С каких пор «разработка под GNOME/Ubuntu» стала синонимом для «разработка на C/C++»? Зачем разработчику нужен этот ваш гнум?
Дальше. Разработка на Си в чистом Эклипсе — это Ъ. Понимаю, что управление сразу несколькими проектами рулит, но почему тогда именно эклипс? Есть же Komodo IDE, Komodo Edit, обе они умеют держать несколько открытых проектов. Писать про различия Eclipse || Eclipse CDT (C/C++ Development Tooling) в следующей части будете?
Дальше. Для «чистой» разработки есть такие прекрасные штуки, как vim, emacs, и куча попыток сделать из них IDE ;).
Если отбросить этот грязный юмор и посмотреть на платные IDE, то можно увидеть, например — виндовый Source Insight, у которого наработан офигенный функционал для человека, пытающегося вчитываться в код, а не запускать его 100500 раз по Ф5. Под линукс аналогов тупо нет, зато с вайном оно совместимо неплохо — за пару лет не упал ни разу. Есть несколько менее замечательный Understand от SciTools, впрочем, у них весь инструментарий неплох, он кроссплатформенный и расширяется. Минус — цена в 800 евро за 1 лицензию ;).
// сейчас меня заминусуют первокурсники с швабодкой и Qt в голове. Господа, давайте не путать учебу, разработку и еще раз разработку?
С каких пор «разработка под GNOME/Ubuntu» стала синонимом для «разработка на C/C++»? Зачем разработчику нужен этот ваш гнум?
Дальше. Разработка на Си в чистом Эклипсе — это Ъ. Понимаю, что управление сразу несколькими проектами рулит, но почему тогда именно эклипс? Есть же Komodo IDE, Komodo Edit, обе они умеют держать несколько открытых проектов. Писать про различия Eclipse || Eclipse CDT (C/C++ Development Tooling) в следующей части будете?
Дальше. Для «чистой» разработки есть такие прекрасные штуки, как vim, emacs, и куча попыток сделать из них IDE ;).
Если отбросить этот грязный юмор и посмотреть на платные IDE, то можно увидеть, например — виндовый Source Insight, у которого наработан офигенный функционал для человека, пытающегося вчитываться в код, а не запускать его 100500 раз по Ф5. Под линукс аналогов тупо нет, зато с вайном оно совместимо неплохо — за пару лет не упал ни разу. Есть несколько менее замечательный Understand от SciTools, впрочем, у них весь инструментарий неплох, он кроссплатформенный и расширяется. Минус — цена в 800 евро за 1 лицензию ;).
// сейчас меня заминусуют первокурсники с швабодкой и Qt в голове. Господа, давайте не путать учебу, разработку и еще раз разработку?
Не умаляя достоинств Source Insight (я не профессиональный разработчик, поэтому оценить не могу) интерфейс у него вырвиглазный.
Не мешает в работе?
Не мешает в работе?
Очередной монстр со 100500 кнопками?
С каких пор «разработка под GNOME/Ubuntu» стала синонимом для «разработка на C/C++»?Перечитайте название статьи, особенно ту часть, где написано «для Ubuntu».
Source Insight, возможно, чудная IDE, но Вы даже не упомянули, умеет ли она собирать и отлаживать код для Linux. Мне почему-то кажется, что не умеет.
Что есть в Source Insight для чтения кода, чего нет в Eclipse? После индексации проекта, в Eclipse можно использовать мощные механизмы поиска. Мне интересно, что еще к ним можно добавить.
Приходилось слышать от начинающих что Eclipse по сравнению с другими IDE требует больше времени для освоения. Тем кому не хватало терпения переходили на тот же Netbeans.
Может и так. Мне судить трудно так как eclipse давно пользуюсь и не помню уже как осваивал. И пользуюсь только им и уже наверно года четыре точно.
Предлагаю автору еще рассмотреть среды разработки с точки зрения ведения проектов. Например:
Есть большой проект который условно состоит из нескольких каталогов
— linux — ядро linux
— drivers — драйвера для ядра
— apps — каталог с приложениями. где каждое приложение — отдельный каталог. Например apps/hello… apps/sound
Есть make-файл в корне который собирает linux драйвера и приложения, но можно зайти в каждый каталог и собрать отдельно.
В Eclipse я могу отдельно создать проект указав каталогом проекта папку «apps» и могу в закладке «Make Target» понаставить цели как в корне каталога, так и в каталоге каждого приложения. И они будут собираться и будет все путем. Могу даже в виде отдельного проекта работать с приложением apps/hello (как проект hello. Мол я работаю только с ним и другие части проекта меня не интересуют так как править я буду только hello)
При этом eclipse будет собирать приложение, если все нормально настроить, видеть хидеры за рамками проекта hello, по клику переходить на них и т.д.
Кроме того как у других IDE дела обстоят с:
— просмотром Call Hierary функции, либо просто где она встречается.
— интеграции с системами контроля версий. На сколько удобно с ними работать, если стоит задача часто отслеживать изменения между версиями, ветками похожих проектов и все сводить.
В те времена когда только определялся со средой разработки, то натыкался на следующее:
— нельзя было собрать в любом каталоге, где есть make-файл а только из корня
— нельзя было создать создать в каталоге с исходниками проект, так что б среда не предложила куда нить эти исходники скопировать.
— систему контроля версий не подхватывала при создании проекта на лету (SVN тот же), как в корне проекта, так и в отдельном каталоге, если исходники уже были поставлены до этого руками из консоли
Ну как то так.
Ну а так, если что то мелкое, то меня и Kate устраивает.
Может и так. Мне судить трудно так как eclipse давно пользуюсь и не помню уже как осваивал. И пользуюсь только им и уже наверно года четыре точно.
Предлагаю автору еще рассмотреть среды разработки с точки зрения ведения проектов. Например:
Есть большой проект который условно состоит из нескольких каталогов
— linux — ядро linux
— drivers — драйвера для ядра
— apps — каталог с приложениями. где каждое приложение — отдельный каталог. Например apps/hello… apps/sound
Есть make-файл в корне который собирает linux драйвера и приложения, но можно зайти в каждый каталог и собрать отдельно.
В Eclipse я могу отдельно создать проект указав каталогом проекта папку «apps» и могу в закладке «Make Target» понаставить цели как в корне каталога, так и в каталоге каждого приложения. И они будут собираться и будет все путем. Могу даже в виде отдельного проекта работать с приложением apps/hello (как проект hello. Мол я работаю только с ним и другие части проекта меня не интересуют так как править я буду только hello)
При этом eclipse будет собирать приложение, если все нормально настроить, видеть хидеры за рамками проекта hello, по клику переходить на них и т.д.
Кроме того как у других IDE дела обстоят с:
— просмотром Call Hierary функции, либо просто где она встречается.
— интеграции с системами контроля версий. На сколько удобно с ними работать, если стоит задача часто отслеживать изменения между версиями, ветками похожих проектов и все сводить.
В те времена когда только определялся со средой разработки, то натыкался на следующее:
— нельзя было собрать в любом каталоге, где есть make-файл а только из корня
— нельзя было создать создать в каталоге с исходниками проект, так что б среда не предложила куда нить эти исходники скопировать.
— систему контроля версий не подхватывала при создании проекта на лету (SVN тот же), как в корне проекта, так и в отдельном каталоге, если исходники уже были поставлены до этого руками из консоли
Ну как то так.
Ну а так, если что то мелкое, то меня и Kate устраивает.
Хочется вставить свои 5 копеек про QtCreator.
Во первых, не понятен пункт «требует установки». В репозиториях он давно есть. На офф сайте, при желании, можно скачать последнюю версию в бинарниках под любую платформу.
Во вторых, qtcreator помимо сборочной системы qmake (pro файлы) поддерживает так же CMake и autotools. Правда редактирование сборочных правил в GUI доступно только для родной системы сборки — qmake, для остальных сборочные правила приходится редактировать ручками.
Отсутствие собственного велосипеда по составлению правил сборки в QtCreator считаю огромным плюсом, т.к. сборка проекта не привязывается к GUI и легко может быть произведена из консоли, без установки IDE.
Во первых, не понятен пункт «требует установки». В репозиториях он давно есть. На офф сайте, при желании, можно скачать последнюю версию в бинарниках под любую платформу.
Во вторых, qtcreator помимо сборочной системы qmake (pro файлы) поддерживает так же CMake и autotools. Правда редактирование сборочных правил в GUI доступно только для родной системы сборки — qmake, для остальных сборочные правила приходится редактировать ручками.
Отсутствие собственного велосипеда по составлению правил сборки в QtCreator считаю огромным плюсом, т.к. сборка проекта не привязывается к GUI и легко может быть произведена из консоли, без установки IDE.
CodeLite еще есть, который несколько лет назад выглядел приятнее, чем Code::Blocks.
QtCreator — слишком слабый автокомплит. В последней версии что смотрел месяца 3 назад он даже от одного typedef переставал работать, про более сильные конструкции, например, с smart_ptr я даже не заикаюсь.
Netbeans — по сути аналог eclipse, но в последнее время сильно сдал.
CodeBlocks — это практически аналог VC6, очень сильно отстал от жизни. Кому хочется понастальгировать по 2000 годам — отличное средство.
Eclipse — наиболее современная и универсальная кросс-платформенная среда, которая позволяет легко интегрировать практически любую систему сборки (например, у меня нажатием 1-ой кнопки происходит сборка нужного бинарника, закачка его и других нужных файлов на удаленную машину, его выполнение по ssh и вывод результата в консоль eclipse — все это с помощью небольшого скрипта на python, который я подсунул eclipse вместо make — при этом не для всего проекта, а только для тех целей сборки которые этого требуют), версионирования (svn, hg, git, perforce), дает неплохие возможности для управления проектами и имеет достаточно хороший редактор с семантической подсветкой кода.
Так же хочу отметить KDevelop, когда с ним работал остался им очень доволен, но было это уже года 3 назад, как с ним сейчас обстоят дела — не знаю.
Ну и для простых проектов я за sublime text, удобно и просто, ничего лишнего, кроме мощнейшего редактора.
Netbeans — по сути аналог eclipse, но в последнее время сильно сдал.
CodeBlocks — это практически аналог VC6, очень сильно отстал от жизни. Кому хочется понастальгировать по 2000 годам — отличное средство.
Eclipse — наиболее современная и универсальная кросс-платформенная среда, которая позволяет легко интегрировать практически любую систему сборки (например, у меня нажатием 1-ой кнопки происходит сборка нужного бинарника, закачка его и других нужных файлов на удаленную машину, его выполнение по ssh и вывод результата в консоль eclipse — все это с помощью небольшого скрипта на python, который я подсунул eclipse вместо make — при этом не для всего проекта, а только для тех целей сборки которые этого требуют), версионирования (svn, hg, git, perforce), дает неплохие возможности для управления проектами и имеет достаточно хороший редактор с семантической подсветкой кода.
Так же хочу отметить KDevelop, когда с ним работал остался им очень доволен, но было это уже года 3 назад, как с ним сейчас обстоят дела — не знаю.
Ну и для простых проектов я за sublime text, удобно и просто, ничего лишнего, кроме мощнейшего редактора.
Netbeans — по сути аналог eclipse, но в последнее время сильно сдал.
По сути, эклипс — аналог NetBeans, если отталкиваться от времени создания.
А по делу, в NetBeans autocomplete и все, что связано с разбором кода всегда осуществлялось через Reflection (команда даже свой Reflection писала, MDR назывался, году в 1999-2000). Никакой парсер ничего похожего не добьется никогда. Правда, я давно заглядывал в эклипс, может они и это уже скопипастили.
В целом kdevelop с тех пор стал стабильнее и быстрее, но гуй местами кажется странным.
Eclipse умеет все, но он тормозит.
QtCreator 2.4.1 (который в репах fc17 и др. дистров) умеет autocomplete для shared_ptr.
В более поздних версиях эта фича периодически ломалась, но я на них не переходил.
В целом между QtCreator с его быстротой (по ощущениям самый быстрый из всех озвученных в посте) но 90% поддержкой С++ и Eclipse с его ужасной скоростью но почти полной поддержкой С++, я выбрал QtCreator.
Ну потому что это же сил нет, такое терпеть в Eclipse, а QtCreator самое важное поддерживает.
QtCreator 2.4.1 (который в репах fc17 и др. дистров) умеет autocomplete для shared_ptr.
В более поздних версиях эта фича периодически ломалась, но я на них не переходил.
В целом между QtCreator с его быстротой (по ощущениям самый быстрый из всех озвученных в посте) но 90% поддержкой С++ и Eclipse с его ужасной скоростью но почти полной поддержкой С++, я выбрал QtCreator.
Ну потому что это же сил нет, такое терпеть в Eclipse, а QtCreator самое важное поддерживает.
По поводу терпения… :)
Да. Соглашусь. Eclipse менее шустрый по сравнению с другими. И прожорливый.
Когда раньше у меня был комп с 1,5 Гб ОЗУ я действительно вешался. Как бы смешно не звучало, но использовал правило «Не устраивает скорость работы Eclipse — смени оконный менеджер на более легковесный...»
Обрезал систему по возможности как можно больше лишь бы освободить памяти и скормить ему… И не давился же… всегда еще мало было… Но все таки удобство работы с ним заставляло терпеть и копить деньги на апгрейд. Звучит бредово, но так и было.
На данном уровне развития конечно же это не актуально, оперативы на всех хватит.
И теперешние его тормоза меня не особенно беспокоят. Шустро кодить я не научился. И пока он подтормаживает (если так можно назвать) успеваю подумать. Мгновенное разворачивание дерева проекта мне не обязательно. Так что для моего ритма работы он подходит. Ну может я просто фанат данной среды, и поэтому в моих глазах это идеальная среда для разработки.
Раздражает больше «искусственная» тормознутость оконных менеджеров при переключении между окнами, реакцию на команду alt-f2 и т.д. Вот это реально бесит так как когда работаешь с несколькими окнами и из-за дефолтных настроек наблюдаешь как красиво «выплывают» окошки.
зы. Спасибо добрым людям за MATE
Да. Соглашусь. Eclipse менее шустрый по сравнению с другими. И прожорливый.
Когда раньше у меня был комп с 1,5 Гб ОЗУ я действительно вешался. Как бы смешно не звучало, но использовал правило «Не устраивает скорость работы Eclipse — смени оконный менеджер на более легковесный...»
Обрезал систему по возможности как можно больше лишь бы освободить памяти и скормить ему… И не давился же… всегда еще мало было… Но все таки удобство работы с ним заставляло терпеть и копить деньги на апгрейд. Звучит бредово, но так и было.
На данном уровне развития конечно же это не актуально, оперативы на всех хватит.
И теперешние его тормоза меня не особенно беспокоят. Шустро кодить я не научился. И пока он подтормаживает (если так можно назвать) успеваю подумать. Мгновенное разворачивание дерева проекта мне не обязательно. Так что для моего ритма работы он подходит. Ну может я просто фанат данной среды, и поэтому в моих глазах это идеальная среда для разработки.
Раздражает больше «искусственная» тормознутость оконных менеджеров при переключении между окнами, реакцию на команду alt-f2 и т.д. Вот это реально бесит так как когда работаешь с несколькими окнами и из-за дефолтных настроек наблюдаешь как красиво «выплывают» окошки.
зы. Спасибо добрым людям за MATE
Пользуюсь QtCreator. До этого перепробовал все, долше всего сидел на Eclipse. Когда перешел на QtCreator это было действительно открытие. Его производительность и удобство поражает. Но вот сейчас мы перешли на с++11 и стало не все так радужно. Сложные шаблоны он гад не может распарсить. Пришлось даже в заголовочных файлах переписать std::shared_ptr чтобы IDE его нормально парсило =)
2.4.1 бустовский shared_ptr нормально парсит. А С++11 я пока в продакшене не применял.
А какая у вас версия креатора?
Я выше уже писал — в некоторых версиях парсинг ломался.
А какая у вас версия креатора?
Я выше уже писал — в некоторых версиях парсинг ломался.
Qt Creator 2.5.0
Я когда тестил 2.5.0 — тоже столкнулся с этой проблемой. Бажный релиз.
В 2.4.1 меньше багов парсинга С++, в т.ч. и есть подержка фич С++11 (auto, lambda).
Так что если вы используете креатор не ради какой-то конкретной версии Qt то попробуйте 2.4.1
Ну еще можно попробовать следующие версии (а их уже несколько).
Вполне вероятно уже пофиксили.
В 2.4.1 меньше багов парсинга С++, в т.ч. и есть подержка фич С++11 (auto, lambda).
Так что если вы используете креатор не ради какой-то конкретной версии Qt то попробуйте 2.4.1
Ну еще можно попробовать следующие версии (а их уже несколько).
Вполне вероятно уже пофиксили.
О, уже 2.6 вышла. Как-то я это пропустил. Сегодня проверю.
Да, 2.6 парсит лучше. Спасибо за совет. Но вот такое:
не парсит. Хотя при этом использование std::shared_ptr парсит. Может его typeid смущает.
template <class Type>
std::shared_ptr<Type> Cache::Get() {
auto table = Get(typeid(Type).name());
return std::shared_ptr<Type>((Type *)table->m_pointer, &Cache::Deleter<Type>);
}
не парсит. Хотя при этом использование std::shared_ptr парсит. Может его typeid смущает.
Табы лечатся в 4.2, но ценой новых неприятностей. Грустно, но хочется верить что все вот-вот станет хорошо!
А параметры нельзя прямо в скрипте запуска прописать? Ну, типа:
PARAM_GTK_1=SMALLTABS PARAM_GTK_2=DWIM eclipse …
Я иногда достаю из шкафа Аптану, так что спасибо мало ;-)
Какие параметры-то, расскажите?
Какие параметры-то, расскажите?
Ну нельзя же все так буквально воспринимать!
И вот теперь:
Или вот так еще, для импорта другой темы:
cat > ~/.gtkrc-2.0-tyny << EOF
style "gtkcompact" {
font_name="Sans 8"
GtkButton::default_border={2,2,2,2}
GtkButton::default_outside_border={0,0,0,0}
GtkButtonBox::child_min_width=0
GtkButtonBox::child_min_heigth=0
GtkButtonBox::child_internal_pad_x=0
GtkButtonBox::child_internal_pad_y=0
GtkMenu::vertical-padding=1
GtkMenuBar::internal_padding=0
GtkMenuItem::horizontal_padding=2
GtkMenuItem::vertical_padding=0
GtkToolbar::internal-padding=0
GtkToolbar::space-size=0
GtkOptionMenu::indicator_size=0
GtkOptionMenu::indicator_spacing=0
GtkPaned::handle_size=4
GtkRange::trough_border=0
GtkRange::stepper_spacing=0
GtkScale::value_spacing=0
GtkScrolledWindow::scrollbar_spacing=0
GtkExpander::expander_size=9
GtkExpander::expander_spacing=0
GtkTreeView::vertical-separator=0
GtkTreeView::horizontal-separator=0
GtkTreeView::expander-size=8
GtkTreeView::fixed-height-mode=TRUE
GtkWidget::focus_padding=0
}
class "GtkWidget" style "gtkcompact"
style "gtkcompactextra" {
xthickness=0
ythickness=0
}
class "GtkButton" style "gtkcompactextra"
class "GtkToolbar" style "gtkcompactextra"
class "GtkPaned" style "gtkcompactextra"
EOF
И вот теперь:
GTK2_RC_FILES=~/.gtkrc-2.0-tiny eclipse
Или вот так еще, для импорта другой темы:
$ cat > ~/.gtkrc-2.0-mytheme << EOF
#To set the Gtk theme
include "/path/to/my/theme/gtkrc"
#To set the icon theme
gtk-icon-theme-name = "MyTheme"
#To set the font
style "Ubuntu"
{
font_name = "Ubuntu 10"
}
widget_class "*" style "Ubuntu"
gtk-font-name = "Ubuntu 10"
EOF
GTK2_RC_FILES=~/.gtkrc-2.0-mytheme eclipse
Очень похоже на обыкновенное перечисление (да и то не полное) IDE. Мало перечислено нюансов использования каждого инструмента. Было бы здорово видеть список критериев, по которым сравниваются перечисленные IDE. Выше уже привели пример с Call Hierary и интеграцией систем контроля версий. Было бы здорово узнать возможности каждой среды по рефакторингу, интеллектуальным подсказкам и кастомизации внешнего вида(для эстетов/любителей темных тем).
Когда я ставил перед собой вопрос выбора IDE для своего проекта на си, ориентировался на кроссплатформенность + возможность генерации проекта cmake'ом. Остановился на Code::Blocks.
Когда программировал под Linux на С++ пробовал много разных IDE. Остановился на KDevelop и vim. Хотя vim — это не полноценная IDE (хотя тут можно поспорить;)). Все остальные не юзабельны (по крайней мере были 2 года назад). Только KDevelop поддерживал вменяемый autocompletion способный распарсить STL и Boost. В нём собственный парсер C++, а не ctags как в большинстве остальных IDE. Ну и в остальном, KDevelop по фичам и удобству далеко впереди остальных IDE.
Из сносных IDE я бы ещё выделил QtCreator. Но он не так хорош как первый. А все остальные Code::Blocks, Anjuta и прочие намного менее функциональны и менее юзабельны.
Отдельно хотел бы предостеречь о использовании Eclipse. Худшей IDE я не видел. Ни для C++, ни для Java. Я всё же готов был простить C++, так как оригинально IDE разрабатывался для Java. Но я попрограммировал немного на Java под Eclipse (небольшой pet project). Ох и настрадался я. Но когда я перешел на Intelli J Idea, я вздохнул с облегчением. Eclipse-у нету прощения. Он должен быть подвергнут анафеме и удален со всех дистрибутивов как вредный для здоровья;)
Из сносных IDE я бы ещё выделил QtCreator. Но он не так хорош как первый. А все остальные Code::Blocks, Anjuta и прочие намного менее функциональны и менее юзабельны.
Отдельно хотел бы предостеречь о использовании Eclipse. Худшей IDE я не видел. Ни для C++, ни для Java. Я всё же готов был простить C++, так как оригинально IDE разрабатывался для Java. Но я попрограммировал немного на Java под Eclipse (небольшой pet project). Ох и настрадался я. Но когда я перешел на Intelli J Idea, я вздохнул с облегчением. Eclipse-у нету прощения. Он должен быть подвергнут анафеме и удален со всех дистрибутивов как вредный для здоровья;)
Приведите аргументы, почему Eclipse настолько плох?
Ну во первых скорость работы. Вообще медленная IDE, но иногда Eclipse задумывается и 1-2 секунды не отвечает. В текстовом редакторе не должно быть задержек при нажатии клавиш. Отклик должен быть мгновенным.
Во вторых. Работа с окнами и видами абсолютно не удобная. Слишком много пространства занято ненужными свистелками. На 21-дюймовом мониторе это не важно. Но я так же работаю и на 11-ти дюймовом ноутбуке с 1024x768. Там 20-30 пикселей убитые на красоту менюшки очень даже пригодились бы. Ну и кто в здравом уме сделает прокрутку как сделано в Eclipse? Что бы появился скроллер надо навести на область где должен быть скрол бар и подождать пол секунды, и переместить мышку на появившийся с боку скролер. Это не просто плохо, это ужасно.
Про авто дополнение я уже писал. Особенно это касается STL, boost и кода где используются шаблоны. Eclipse справляется намного хуже.
Подсветка синтаксиса в Eclipse сделана ужасно. Вот пример одного и того же файла открытого в двух средах Eclipse и KDevelop:
Догадайтесь где тут Eclipse;)
Ну и в остальном по мелочам. Ну и если быть вообще субъективным. Как то не получаю удовольствие от программирования в Eclipse. Множество раздражающих факторов, которые негативно влияют на работу и продуктивность. Другое дело KDevelop или IntelliJ Idea. Когда я программирую в них, то я их просто не замечаю. Я пишу код, а не борюсь с IDE.
Во вторых. Работа с окнами и видами абсолютно не удобная. Слишком много пространства занято ненужными свистелками. На 21-дюймовом мониторе это не важно. Но я так же работаю и на 11-ти дюймовом ноутбуке с 1024x768. Там 20-30 пикселей убитые на красоту менюшки очень даже пригодились бы. Ну и кто в здравом уме сделает прокрутку как сделано в Eclipse? Что бы появился скроллер надо навести на область где должен быть скрол бар и подождать пол секунды, и переместить мышку на появившийся с боку скролер. Это не просто плохо, это ужасно.
Про авто дополнение я уже писал. Особенно это касается STL, boost и кода где используются шаблоны. Eclipse справляется намного хуже.
Подсветка синтаксиса в Eclipse сделана ужасно. Вот пример одного и того же файла открытого в двух средах Eclipse и KDevelop:
Догадайтесь где тут Eclipse;)
Ну и в остальном по мелочам. Ну и если быть вообще субъективным. Как то не получаю удовольствие от программирования в Eclipse. Множество раздражающих факторов, которые негативно влияют на работу и продуктивность. Другое дело KDevelop или IntelliJ Idea. Когда я программирую в них, то я их просто не замечаю. Я пишу код, а не борюсь с IDE.
Вы так красноречиво заплевали Eclipse и предостерегали его использовать так, что я прям предостережения о конце света стали мелочью. С ходу поставил Kdevelop сокрушаясь как я мог четыре года разрабатывать приложения в «этой недо-IDE»
Поставил. Решил пройтись по тем критериям о которых писал в своих комментах выше.
1. Проект импортировался быстро, никуда переносить не стал — порадовало. Никаких прогресов по индексации не показывал. Странно. Тест пройден.
2. SVN подхватил, хоть импортировал часть проекта как подпроект — супер. Тест пройден.
3. По мере редактирования файлов по системой контроля версий в дереве проекта меняются значки, где наглядно видно что данный файл отредактирован, другой — не под версией и т.д. Тут ничего такого не вижу. Тест не пройден
4. В Eclipse интеграця системы контроля версий более обширна. Могу:
— заменить последней версией из репозиториев, если зашел в тупик
— сравнить файл/каталог в последней версией, а так же с любым исходником в любой ветви SVN любого репозитория, да и просто другой ветки в каталоге проекта — тут ничего такого нет.
— не ставил под версию но правил файл — могу посмотреть локальную историю.
5. Call Hierarhy функцию. С ходу открыл один из демонов, кликнул на функции main() и вызывал «find uses». В рамках проекта около 20 демонов, тем не менее находило 5. Я в не понятках. Либо он индексирует в фоне и пока не все прошел… Уж лучше как в Eclipse — напрямую в течении 20 минут проходит ядро linux… При этом работать в среде не возможно, но зато после этого по всему ядру Eclipse ходит шустро. Либо нужно что то настраивать, но в eclipse не нужно. Тест пройден кое-как // Дадим шанс данной Среде
6. В любом исходнике кода в Eclipse я могу навести грызуна на используемую функцию — в хинте покажется ее реализация. Если нужно подобрнее — ctrl+Клик. — перейдет. Если такая функция есть в нескольких модулях (в разных демонах) покажет диалоговое окно с списком файлов куда можно перейти. В к KDevelop — фик. Тест не пройден.
7 Сборка каждого демона либо библиотеки по отдельности — не нашел как сделать либо нет вообще. Тест не пройден.
8. Сплитить исходники в Eclipse могу просто перетаскивая закладку — тут нужно по команде кликая на закладке и выбирать «Split View...».
9. Любую из панелей могу свернуть предоставив побольше места на мониторе для другой. Тут я вижу только крестик закрытия.
И много еще чего мог бы вкусного по eclipse рассказать… И это узнаешь по мере использования а не за 15 минут изучения среды. Так что допускаю что и Kdevelop я не рассмотрел достаточно, но отмеченное выше для меня критично и намного больше чем автодополнение кода и скорость работы.
Да. кста не отметил. Я кожу на C а не на С++. Поэтому не исключаю что я тут занимаюсь офтопом по отношению к названию статьи. Но я рассмотрел возможности среды с точки зрения ее использования. И Eclipse будет одинаково по этим параметра работать с любым языком который вы решили использовать.
Зы. Бережно протер тряпочкой оплеванный Eclipse, снес kDevelop. Продолжил работать…
Поставил. Решил пройтись по тем критериям о которых писал в своих комментах выше.
1. Проект импортировался быстро, никуда переносить не стал — порадовало. Никаких прогресов по индексации не показывал. Странно. Тест пройден.
2. SVN подхватил, хоть импортировал часть проекта как подпроект — супер. Тест пройден.
3. По мере редактирования файлов по системой контроля версий в дереве проекта меняются значки, где наглядно видно что данный файл отредактирован, другой — не под версией и т.д. Тут ничего такого не вижу. Тест не пройден
4. В Eclipse интеграця системы контроля версий более обширна. Могу:
— заменить последней версией из репозиториев, если зашел в тупик
— сравнить файл/каталог в последней версией, а так же с любым исходником в любой ветви SVN любого репозитория, да и просто другой ветки в каталоге проекта — тут ничего такого нет.
— не ставил под версию но правил файл — могу посмотреть локальную историю.
5. Call Hierarhy функцию. С ходу открыл один из демонов, кликнул на функции main() и вызывал «find uses». В рамках проекта около 20 демонов, тем не менее находило 5. Я в не понятках. Либо он индексирует в фоне и пока не все прошел… Уж лучше как в Eclipse — напрямую в течении 20 минут проходит ядро linux… При этом работать в среде не возможно, но зато после этого по всему ядру Eclipse ходит шустро. Либо нужно что то настраивать, но в eclipse не нужно. Тест пройден кое-как // Дадим шанс данной Среде
6. В любом исходнике кода в Eclipse я могу навести грызуна на используемую функцию — в хинте покажется ее реализация. Если нужно подобрнее — ctrl+Клик. — перейдет. Если такая функция есть в нескольких модулях (в разных демонах) покажет диалоговое окно с списком файлов куда можно перейти. В к KDevelop — фик. Тест не пройден.
7 Сборка каждого демона либо библиотеки по отдельности — не нашел как сделать либо нет вообще. Тест не пройден.
8. Сплитить исходники в Eclipse могу просто перетаскивая закладку — тут нужно по команде кликая на закладке и выбирать «Split View...».
9. Любую из панелей могу свернуть предоставив побольше места на мониторе для другой. Тут я вижу только крестик закрытия.
И много еще чего мог бы вкусного по eclipse рассказать… И это узнаешь по мере использования а не за 15 минут изучения среды. Так что допускаю что и Kdevelop я не рассмотрел достаточно, но отмеченное выше для меня критично и намного больше чем автодополнение кода и скорость работы.
Да. кста не отметил. Я кожу на C а не на С++. Поэтому не исключаю что я тут занимаюсь офтопом по отношению к названию статьи. Но я рассмотрел возможности среды с точки зрения ее использования. И Eclipse будет одинаково по этим параметра работать с любым языком который вы решили использовать.
Зы. Бережно протер тряпочкой оплеванный Eclipse, снес kDevelop. Продолжил работать…
Если вы привыкли к Eclipse и он вам удобен, не буду агитировать к чему то другому. Выбор IDE очень субъективная вещь.
Отвечу по нескольким пунктам.
У меня совершенно другой опыт с распознаванием кода и автодополнением. В моих тестах Eclipse не мог найти реализацию методов, а KDevelop с этим справлялся. С голым C ситуация конечно попроще. Наверняка и Eclipse не имеет проблем с этим. Странно правда почему у вас KDevelop не нашел всех реализаций.
Да KDevelop не показывает реализацию в тултипе. Но показывает подсказку с определением метода. Можно выбрать — declaration, definition или usages.
Сборка каждого модуля по отдельности. В каждом модуле есть элемент на который можно кликнуть и выбрать build. Так же можно выбрать build на отдельной директории.
Что бы схлопнуть панельку просто потащите вниз за вот этот элемент
Как я писал выше, у меня был негативный опыт работы с Eclipse. И позитивный опыт с другими IDE. Если вас он устраивает, я не имею ничего против. Ладно уговорили, Eclipse можно оставить в дистрибутивах;) Но предупреждать о вредный психического здоровья при запуске всё же надо;)
Отвечу по нескольким пунктам.
У меня совершенно другой опыт с распознаванием кода и автодополнением. В моих тестах Eclipse не мог найти реализацию методов, а KDevelop с этим справлялся. С голым C ситуация конечно попроще. Наверняка и Eclipse не имеет проблем с этим. Странно правда почему у вас KDevelop не нашел всех реализаций.
Да KDevelop не показывает реализацию в тултипе. Но показывает подсказку с определением метода. Можно выбрать — declaration, definition или usages.
Сборка каждого модуля по отдельности. В каждом модуле есть элемент на который можно кликнуть и выбрать build. Так же можно выбрать build на отдельной директории.
Что бы схлопнуть панельку просто потащите вниз за вот этот элемент
Как я писал выше, у меня был негативный опыт работы с Eclipse. И позитивный опыт с другими IDE. Если вас он устраивает, я не имею ничего против. Ладно уговорили, Eclipse можно оставить в дистрибутивах;) Но предупреждать о вредный психического здоровья при запуске всё же надо;)
Кате вместе с CMake, остальное от лукавого
Добавьте пожалуйста в описание совместимость с Cmake. К примеру Eclipe ужасно совместим с Cmake, приходится постоянно делать различные телодвижения что бы работать с проектом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Среды разработки С++ для Ubuntu