Комментарии 157
НЛО прилетело и опубликовало эту надпись здесь
С точки зрения языка — поддержка одинаковая. Отличаются они скорее набором тулов. AppCode — использует Xcode build и Xcode проектную модель. CLion — CMake и GCC/Clang компиляторы. Плюс, CLion кросс-платформенный, а AppCode только для мака.
Вообще про все наши C++ мы попытались расписать случаи использования здесь — www.jetbrains.com/cpp
Вообще про все наши C++ мы попытались расписать случаи использования здесь — www.jetbrains.com/cpp
В основном описание функций (вроде как) всех Ваших IDE
Основные отличия и правда только в тулзах + генерация, если правильно понял нереализованных методов из интерфейсов?
Хотелось бы увидеть чем отличается от штормов, идеи и пайчарма) Какие именно вещи помимо тех, которые все и так ожидали увидеть))
И огромное спасибо и уважение! Работа коллосальная! Крупные проекты протестирую сегодня же вечером))
Основные отличия и правда только в тулзах + генерация, если правильно понял нереализованных методов из интерфейсов?
Хотелось бы увидеть чем отличается от штормов, идеи и пайчарма) Какие именно вещи помимо тех, которые все и так ожидали увидеть))
И огромное спасибо и уважение! Работа коллосальная! Крупные проекты протестирую сегодня же вечером))
Встроенный отладчик с использованием gdb или все таки lldb?
Синхронизацию шортактов сделали или пользователям предстоит ручками мучиться?
В каком смысле синхронизацию? Доступны стандартные раскладки IntelliJ IDEA, ReSharper, Xcode, Emacs, Vim, Eclipse, VS и др. Можно, как и в любой другой IDE от JetBrains на платформе IntelliJ заэкспортить свою кастомную раскладку, и заимпортить ее потом в CLion.
А как связаны доступные раскладки и синхронизация?
Речь идет о синхронизации между приложением установленным на разных компьютерах пользователя без мучений. В идеале: синхронизация между различными продуктами, ведь очень многие действия по редактированию пересекаются. Совсем вы идеале: синхронизация настроек инспекции в пределах компании.
Настройка под себя это та еще мука, но необходимость это проделывать для каждого форка IDEA…
Речь идет о синхронизации между приложением установленным на разных компьютерах пользователя без мучений. В идеале: синхронизация между различными продуктами, ведь очень многие действия по редактированию пересекаются. Совсем вы идеале: синхронизация настроек инспекции в пределах компании.
Настройка под себя это та еще мука, но необходимость это проделывать для каждого форка IDEA…
Вы можете попробовать Settings Repository плагин. Он позволяет синхронизировать настройки при помощи git репозитория. Пока что плагин сыроват, поэтому он не особо рекламируется
Интересная вещь, посмотрю. Но сторонний продукт такого рода вызывает сомнения: нет гарантий, что он будет совместим с новыми версиями IDE.
Пользуюсь различными продуктами JB лет 5 и до сих пор не понимаю, как при таком чудовищном количестве шорткатов и такой глубокой возможностью кастомизации не запилить такую простую вещь как синхронизация настроек…
Пользуюсь различными продуктами JB лет 5 и до сих пор не понимаю, как при таком чудовищном количестве шорткатов и такой глубокой возможностью кастомизации не запилить такую простую вещь как синхронизация настроек…
Плагин разработан сотрудниками JB.
Мне кажется, кастомизация шорткатов — не слишком частое действие. Один раз настроил, экспортировал, кинул на какой-нибудь dropbox, и потом на всех машинах при необходимости импортируешь.
Хотя, конечно, синхронизация — интересная идея, но вряд ли стоит делать ее приоритетной.
Хотя, конечно, синхронизация — интересная идея, но вряд ли стоит делать ее приоритетной.
Решили ли проблему с производительностью? При работе с boost::multi_index_container ide зависала очень надолго.
Надо пробовать. Какие-то проблемы решили, какие-то еще остались, какие-то в разработке сейчас. Нам, чтобы разобраться, очень полезен CPU snapshot (https://intellij-support.jetbrains.com/entries/29983118-Reporting-performance-problems) или пример проекта, где проблемы. Мы, конечно, тестируем сами на больших проектах, особенно с boost, но, наверняка, многого не замечаем. Так что если вы попробуете и нам расскажите, то мы будем благодарны.
А есть подобная инструкция для R# C++? Установил в пятницу «на попробовать», создается такое впечатление, что он работает все медленнее и медленнее :(
Да, есть, здесь: resharper-support.jetbrains.com/entries/24083148-Visual-Studio-with-ReSharper-is-slow
Если кратко, то путь следующий: ReSharper > Help > Profile Visual Studio, затем выполнить тормозящие операции под профилятором. После этого вы можете отправить нам снепшот из того же окна (анонимизированная информация о системе собирается автоматически и прикрепляется к тикету).
Если кратко, то путь следующий: ReSharper > Help > Profile Visual Studio, затем выполнить тормозящие операции под профилятором. После этого вы можете отправить нам снепшот из того же окна (анонимизированная информация о системе собирается автоматически и прикрепляется к тикету).
Это просто отличная новость!
Но, увы, у меня не получилось купить лицензию с помощью Яндекс.Денег i.imgur.com/BNt5CL4.png :(
Но, увы, у меня не получилось купить лицензию с помощью Яндекс.Денег i.imgur.com/BNt5CL4.png :(
Я смотрю, CLion знает типы переменных, отображает их при нажатии Ctr+Q. А нельзя ли также сделать отображение типа без документации через Alt+=? У меня, как, вероятно, и у многих других пользователей продукции JetBrains, мышечная память на него :) И еще вопрос. Планируется ли добавить полноценный вывод типа для auto переменных? Сейчас это работает только в обычном коде, но не в шаблонах i.imgur.com/uvxCWXM.png
Не только в шаблонах, в моем проекте вывод auto ломается и на более простых примерах.
Печаль. А как на этих примерах ведет себя Eclipse CDT? Я просто знаю под Linux только две IDE для С++, умеющие выводить типы — Eclipse и CLion.
Про CDT не знаю, давно ушел от него. Есть еще KDevelop — он справляется. Но я не пользуюсь, в случае проблем с CLion откатываюсь в emacs, например когда в шаблонном коде начинаются сильные тормоза редактора.
QtCreator тоже выводит, но сложные шаблоны пока не тянет
Ой, а каким хоткеем в QtCreator посмотреть тип? Я читал их шпаргалку по хоткеям и не нашел. Может посоветуете туториал какой-нибудь или иного рода учебный материал по этой теме?
Это только при использовании Clang в качестве парсера (он жутко медленный). Стандартные средства не могут вывести тип объекта, если указатель на него хранится в шаблонном контейнере.
Тут автодополнение ломается.
std::vector<MyClass*> vec;
...
vec[0]->
Тут автодополнение ломается.
Не совсем так, шаблоны он парсит, к примеру замените std::vector на QVector, и это не зашитое поведение, в этом тоже легко убедиться. Но std::vector это не просто шаблон (tm), с ним не справляется, возможно — чрезвычайная сложность шаблона сказывается, возможно сам шаблон явно или косвенно использует особенности реализации gcc о которых QtCreator не знает
Вообще эти примеры — откровенные баги, их исправят наверняка. А вот чтобы в вашем примере auto0 выводился в T — тут явно требуются нехилые средства для анализа шаблонов. Нужно понять, что decltype(*std::begin(std::vector{})) это тот же самый T, которым параметризован вектор, думаю не самая простая задача.
Шорткат quick documentation можете сами поправить на тот, который Вам больше нравится в Settings | Keymap. Или еще можно воспользоваться quick definition — Ctrl+Alt+B (в дефолтовой раскладке).
Да, над auto работа ведется. Прямо сейчас. Надеемся, станет лучше.
Да, над auto работа ведется. Прямо сейчас. Надеемся, станет лучше.
Напишите на sales@jetbrains.com, пожалуйста.
Имеется ли у вас статистика по количеству коммерческих проектов на Windows под компиляторы Cygwin или MinGW? Планируется ли в Clion поддержка компиляторов от MS VC и Intel C++ Compiller? Имеется ли публичный RoadMap на следующий релиз(ы)?
Да, странно, что самые популярные компиляторы для Windows не поддерживаются.
Для использования MSVC предназначен наш другой продукт — ReSharper C++ (https://www.jetbrains.com/resharper-cpp/) — плагин для VS.
Вообще согласно нашим исследованиям почти половина тех, кто разрабатывает на Windows платформе, используют именно Cygwin/MinGW окружение. Поэтому на платформе Windows мы предлагаем на выбор два продукта — CLion и ReSharper C++.
Intel компилятор — мы планируем его поддержать в будущем. RoadMap пока обсуждается.
Вообще согласно нашим исследованиям почти половина тех, кто разрабатывает на Windows платформе, используют именно Cygwin/MinGW окружение. Поэтому на платформе Windows мы предлагаем на выбор два продукта — CLion и ReSharper C++.
Intel компилятор — мы планируем его поддержать в будущем. RoadMap пока обсуждается.
>почти половина тех, кто разрабатывает на Windows платформе, используют именно Cygwin/MinGW окружение
Речь идёт именно о коммерческих проектах или CLion ориентирован больше на OpenSource и любительские разработки, где действительно обычно используются Cygwin/MinGW?
Речь идёт именно о коммерческих проектах или CLion ориентирован больше на OpenSource и любительские разработки, где действительно обычно используются Cygwin/MinGW?
Хоть я и целиком и полностью за mingw под windows, сделайте возможность вместо cmake запускать произвольную программу в настраиваемом окружении (ну или хотя-бы параметры от проекта передавать в аргументы, дальше можно уже самому доделать).
Понимаю что с cmake у вас интеграция выходит за рамки системы сборки, но вариант «папка с отображением дерева файлов»+вызывать программу компиляции — как минимум решит проблему управления проектами, а если приплюсовать сюда требования скрипта возвращающего дефайны + инклюды — можно получить уже вполне рабочее автодополнение.
Попробуйте так сделать, отметьте эту фичу как нестабильное временное решение, я думаю комьюнити вас поддержит в плане совместимости с системами сборки если вы дадите ему такую возможность.
Понимаю что с cmake у вас интеграция выходит за рамки системы сборки, но вариант «папка с отображением дерева файлов»+вызывать программу компиляции — как минимум решит проблему управления проектами, а если приплюсовать сюда требования скрипта возвращающего дефайны + инклюды — можно получить уже вполне рабочее автодополнение.
Попробуйте так сделать, отметьте эту фичу как нестабильное временное решение, я думаю комьюнити вас поддержит в плане совместимости с системами сборки если вы дадите ему такую возможность.
В CMake умеет сам использовать любой тулчейн, хоть sysroot указывайте и под другую платформу собирайте. Так что использование другого компилятора реализовано самим CMake. Другой вопрос, что CLion не поддерживает remote-debug, что сильно ограничивает область его применения. Ну серьёзно, это же C++, отладка на таргет системах — первое что нужно было реализовывать.
Просто для сборки запускать можно что угодно при помощи функции External Tools.
Что касается проектной модели — идеального, подходящего всем варианта не существует, а с чего-то нужно было начинать. Решили начать с CMake.
Что касается проектной модели — идеального, подходящего всем варианта не существует, а с чего-то нужно было начинать. Решили начать с CMake.
Есть еще «дешевый» вариант — поддержка clang-cl. Он позволит поддерживать синтаксис MSVC при сохранении поддержки бэкенда в виде llvm/clang.
Почему убрали поддержку Linux 64-bit, планируется ли вернуть?
Расскажите, много ли покупателей в первый день? Ведь мы все так ждали :-)
Вчера вечером скачал дома, посмотрел…
Подтормаживает. Хотя это не к вам претензия, для софта на джаве это вообще характерная черта:)
Интерфейс внешне приятный, темная тема есть, проверять в работе не стал — нет у меня проектов на cmake.
Самая быстрая ide на сегодня — это qt creator. Но он неудобный, в нем нет даже закладок из коробки (какие-то плагины есть, который под виндой работают а под линуксом не собираются). Не говоря уже о совершенно странном и неудобном поведении вспомогательных окон.
А все что удобное — тормозит (включая visual studio). Ну вот почему так?
Пробовать в любом случае буду, но когда сделаете поддержку проектов на основе qmake (файлы .pro) и visual studio (vcxproj / sln).
Подтормаживает. Хотя это не к вам претензия, для софта на джаве это вообще характерная черта:)
Интерфейс внешне приятный, темная тема есть, проверять в работе не стал — нет у меня проектов на cmake.
Самая быстрая ide на сегодня — это qt creator. Но он неудобный, в нем нет даже закладок из коробки (какие-то плагины есть, который под виндой работают а под линуксом не собираются). Не говоря уже о совершенно странном и неудобном поведении вспомогательных окон.
А все что удобное — тормозит (включая visual studio). Ну вот почему так?
Пробовать в любом случае буду, но когда сделаете поддержку проектов на основе qmake (файлы .pro) и visual studio (vcxproj / sln).
del
Посмотрите багтрекер CMake. У них до сих пор проблемы с генерацией проектов под разные IDE, а они над этим работают очень долго. Даже у VS бывают проблемы при «импорте» проектов из старых версий самой себя. Мне кажется это будет самоубийство для Jetbrains :)
CMake это очень правильный выбор, снимает столько головняков с разработчиков JB. И для пользователей тоже удобно — не нравится CLion, генерируй проект под свою IDE.
CMake это очень правильный выбор, снимает столько головняков с разработчиков JB. И для пользователей тоже удобно — не нравится CLion, генерируй проект под свою IDE.
А все что удобное — тормозит (включая visual studio). Ну вот почему так?
Это глобальный тренд в разработке IDE уже много лет. Всегда стоит выбор:
1. Нагромоздить кучу фич, научить среду разработки понимать и анализировать код на ходу, при разработке использовать средства, позволяющие разрабатывать быстро и много.
2. Выжимать максимум производительности, экономить на всём, ударяться в оптимизации всегда и везде, в том числе в ущерб реализации новых фич.
В какой-то момент пришло осознание, что производительность программиста возрастает, если ему дать мощную, но тормозящую среду, но при этом тормоза не настолько зашкаливающие, что программист начинает материться раз в минуту. Если тормоза можно уменьшить наращиванием RAM, SSD и т.п. — вообще отлично, потому что железо гораздо дешевле программиста. Поэтому, если раньше подход был «если задержка 50 мс, то пора оптимизировать», то сейчас «если в пределах 400 мс, то жить можно, зато вон сколько фич».
Представьте, что лет 10-15 назад вам сказали бы, что передовая среда разработки для C++ будет написана на Java — вы бы не рассмеялись?
Ну вот qt creator не тормозит, и фичи все есть… другое дело что интерфейс построен так коряво, что до этих фичей просто не добраться.
Тут можно поспорить. Мне интерфейс Qt Creator очень нравится. Есть архитектурные заскоки (как минимум связанные с Baremetal плагином) и поддержка CMake оставляет желать лучшего. Плюс сложные конструкции кода временами отказывается воспринимать. Причём, бывает сложно собрать «минимально-рабочий пример» на котором наблюдаешь ошибку. Подключение CLang парсера спасает, но уже не раз ловил его падение, а про тормоза и говорить нече. Ну и функционала по рефакторингу хотелось бы побольше и поштабильнее (бывает что на коде просто не появляется меню, когда хочешь сделать Extract function). Фичи с хранением результатов разбора на диске, тоже не хватает: был проект который парсировался около 10 минут. Добавил файл — снова иди пить чай. Хотя фича сложная, особенно понять что и как обновлять.
Но всё же как-то научились жить вместе.
Но всё же как-то научились жить вместе.
что передовая среда разработки для C++ будет написана на Java — вы бы не рассмеялись?
Я и сейчас рассмеюсь. До «передовой» CLion'у нужно побороть студию и QT Creator, а в ближайшие годы этого не произойдёт — нет никаких предпосылок и уникальных фич.
НЛО прилетело и опубликовало эту надпись здесь
Да качал, качал. Не понял только, что мне с этим делать. Рабочие проекты (студийные, немного завязанные на C++\CLI) в ней не откроешь. Домашние (в основном Qt) — аналогично, да и незачем. Новый проект с интерфейсом — не сделаешь. Хеллоу Ворлд написать да, можно. Можно небольшую консольную утилиту. Но это всё можно и в блокноте написать. В общем, пока применения не придумал.
Студию побороли уже: они на всех платформах и это IDE.
Возможно вы парируете это настраиваемостью проекта. На что я замечу, что CMAKE куда гибче, а то, что пока это не GUI так не велика беда. Зато новые фишки проще внедрять.
Про QTCreator сказать не могу, не трудился в нём. Но вроде основная фишка — создание интерфейсов, разве нет? Чего в СиЛайоне пока нету (или не нашёл) и появится в скором времени (или найду).
Возможно вы парируете это настраиваемостью проекта. На что я замечу, что CMAKE куда гибче, а то, что пока это не GUI так не велика беда. Зато новые фишки проще внедрять.
Про QTCreator сказать не могу, не трудился в нём. Но вроде основная фишка — создание интерфейсов, разве нет? Чего в СиЛайоне пока нету (или не нашёл) и появится в скором времени (или найду).
«Побороли Студию» будет тогда, когда разработчики следующей ААА-игры или чего-то подобного по размаху скажут «да, пришлось выкинуть студию и взять CLion». А по факту Вин-разработчики со студии не уйдут, маководы влюблены в свой икскод, а линуксоиды в основном сидят в виме, обвешанном сотней плагинов. Да, любители опенсорса, студенты и стартаперы получат от CLion некоторый профит, но до мейнстрима тут далеко.
Что касается создание интерфейсов — то мне интересно, как оно там может появиться и выглядеть? Студия для С++ предлагает либо MFC с его визардами и редактором интерфейсов, либо WinForms\WPF (через C++\CLI), либо DirectX со средствами отладки сцен. Qt Creator, понятное дело, предлагает Qt. А какие возможности создания интерфейсов может предложить CLion?
Что касается создание интерфейсов — то мне интересно, как оно там может появиться и выглядеть? Студия для С++ предлагает либо MFC с его визардами и редактором интерфейсов, либо WinForms\WPF (через C++\CLI), либо DirectX со средствами отладки сцен. Qt Creator, понятное дело, предлагает Qt. А какие возможности создания интерфейсов может предложить CLion?
Все что касается IDE это все очень субъективно. Лично я GUI делаю в Eclipse CDT + Qt Designer, и лично для меня это намного удобней чем QtCreator. И знаю людей, для которых это удобно делать в Vim, Emacs, NetBeans, KDevelop, Code::Blocks.
Варинтов не так много: gtk и Qt. Каждый из них имеет готовые инструменты для компиляции под другие платформы.
Разработчики игр, если честно, странный показатель. Там всё, __, заточено под винды и немножко под маки: IDE для С++, фотошопы, запекатели карт, унструменты движков (UrealEngine, Unity). Многие инструменты имеют возможность взаимодействовать с другими. Там попросту нет нужды, мотивации и интереса менять на СайЛайон студию, которая для игр отлично себя показала.
Но не играми одними С++ и Си дышит: приложения, встраиваемый софт, драйвера и, если прикинуть, можно нарыть десятки отраслей, где разработчикам винда как кость в горле, где приходится обвешиваться мингв и сигвином чтобы всё это собирать. Мак тоже показал негативный опыт для ряда системщиков из старой школы.
Так что если вы способны осознать в каких областях KDevelop нагибает и составляет конкуренцию остальным средам, то способны и понять для каких областей СайЛайон это глоток свежего воздуха =)
Разработчики игр, если честно, странный показатель. Там всё, __, заточено под винды и немножко под маки: IDE для С++, фотошопы, запекатели карт, унструменты движков (UrealEngine, Unity). Многие инструменты имеют возможность взаимодействовать с другими. Там попросту нет нужды, мотивации и интереса менять на СайЛайон студию, которая для игр отлично себя показала.
Но не играми одними С++ и Си дышит: приложения, встраиваемый софт, драйвера и, если прикинуть, можно нарыть десятки отраслей, где разработчикам винда как кость в горле, где приходится обвешиваться мингв и сигвином чтобы всё это собирать. Мак тоже показал негативный опыт для ряда системщиков из старой школы.
Так что если вы способны осознать в каких областях KDevelop нагибает и составляет конкуренцию остальным средам, то способны и понять для каких областей СайЛайон это глоток свежего воздуха =)
Пока что в CLion нет средств для разработки UI. И вряд ли в самое ближайшее время появятся. Но позже мы об этом обязательно подумаем.
Но вроде основная фишка — создание интерфейсов, разве нет?
Нет. Много юзаю для всякого baremetal. При наличии Generic project manager вообще сказка: прикручивается к любой системе сборки. Плюс есть возможность сделать свой Мастер новых проектов, который умеет вызывать скрипт (точнее что угодно исполняемое): у меня так генерировался generic проект для жуткой легаси базы, куда из всего дерева брались только нужные файлы, что сильно экономило время на открытие проекта, могло вызывать дополнительные диалоги для задания параметров и т.п.
Это на каком проекте?)
Открывал мозиллу (вот уж точно грохнуться можно, а не проект: питон и плюсы с бустом и ГТК разных версий) когда была бетта и никаких тормозов после индексации. Правда компик не из слабых пк…
Джаву можно сильно ускорить gcj и если покапаться есть ещё плюшка) Но лагов (подтормаживаний) уже давно не было на амд-шных камнях, но бывали на интелах… (уж не камни в огороды процов, а наблюдения).
Открывал мозиллу (вот уж точно грохнуться можно, а не проект: питон и плюсы с бустом и ГТК разных версий) когда была бетта и никаких тормозов после индексации. Правда компик не из слабых пк…
Джаву можно сильно ускорить gcj и если покапаться есть ещё плюшка) Но лагов (подтормаживаний) уже давно не было на амд-шных камнях, но бывали на интелах… (уж не камни в огороды процов, а наблюдения).
Как это нет закладок? Ctrl+M — установить закладку. Ctrl+< Ctrl+> — переход. Это из коробки. На Linux.
Всё это хорошо, но теперь я начинаю ждать вашу IDE для Rust…
Есть подозрения, что ближайшие лет 5 это не бизнес приоритетная задача ))) Точно не более приоритеная, чем нормальная поддержка скажем Haskell. Но тут энтузиастом пилится плагин для Rust github.com/Vektah/idea-rust
Я видел этот плагин, он умеет только раскрашивать. Плагины энтузиастов обычно и пилятся годами, а функционал бывает очень слаб.
Rust это будущее, он способен заменить старого, разваливающегося C++. Поэтому, я считаю, что тот, кто запилит полнофункциональную IDE для Rust может рассчитывать на хорошую материальную поддержку.
Rust это будущее, он способен заменить старого, разваливающегося C++. Поэтому, я считаю, что тот, кто запилит полнофункциональную IDE для Rust может рассчитывать на хорошую материальную поддержку.
И как много крупных коммерческих проектов на этом языке вы знаете? Или откуда ещё взяться этой материальной поддержке хорошей?
Хорошо, давайте ничего не писать под новые языки, пускай они не имеют возможности развиваться. Энтузиасты запилят костыль тут и костыль там. А мы будем продолжать стрелять себе в ноги хорошо изученным языком.
Rust, бесспорно, интересный язык. Но тут проблема курицы и яйца. Пока на нем никто не пишет, нет инструментов и вакансий. Пока нет инструментов и вакансий, это никому не интересная игрушка. А то что плагин медленно пишется — ну так вы автору занесите, может разработка и ускорится. Racer хотя бы прикрутит, уже прогресс огромный будет.
Добро пожаловать в Xcode с поддержкой языка Swift ) судя по примерам из Wikipedia Apple очень много позаимствовал из Rust для своего нового языка… чуть ли не все основные идеи. Так что вам должно понравится.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
В чем проблема установить в windows тот же (или максимально похожий) шрифт, что вы используете в os x? Другое дело, что сам рендеринг шрифтов в разных ОС работает по-разному, но тут уж ничего не поделать.
Consolas пробовали?
Насколько я знаю, рисованием шрифтов мы пока ещё не озадачивались.
Я тут насмотревшись на OSX поставил нагло своровав его с макоси себе Aythaya, и вполне доволен!
Есть правда одна особенность — я через fontforge выпилил хинты из шрифта, и только после этого он стал выглядеть красиво)
Скрин
Простите меня за PHP :)
Есть правда одна особенность — я через fontforge выпилил хинты из шрифта, и только после этого он стал выглядеть красиво)
Stop/restart при дебаге починили, интересно?
Ну и поддержка тулчейнов пока очень ограниченная, ждем в следующих версиях.
Ну и поддержка тулчейнов пока очень ограниченная, ждем в следующих версиях.
Если скажите о каком тикете идет речь — посмотрим в трекере. Ну, или попробуйте) Потом поделитесь результатом — будем благодарны. По дебагеру были фиксы в последних EAP-ах, но о чем вы конкретно, не могу сходу сказать.
По трекеру никакой активности: youtrack.jetbrains.com/issue/CPP-1807
Я прирос к семантической подсветке — программирую в kdevelop. Часто приходится копаться в чужих исходниках, сильно помогает быстро мозгом схватить весь dataflow. А синтаксическую начал ненавидеть, только мешает, мозг совсем не на том концентрируется. Особенно с умолчательными вырви-глазными цветами. Надеялся, что здесь будет, а попробовал триал — нет. В эклипсе есть, у микрософта есть, даже в нетбинс уже есть, и даже в саблайм через отдельный модуль, а тут нет, печаль. Сделайте пожалуйста! Буду ждать, я терпеливый )
Да, очень не хватает.
Не знал, что такое вообще бывает. Спасибо :) Но не нашел как это включить в Scala Plugin. Неужто там нет?
А могли бы прощупать как следует клион (поработать) и сказать ощущения помимо этого?) (по мне кдевелоп пока ведущая ИДЕ под линухами, но это лишь вкусовщина)))
Он произносится как си-лайон, «морской лев», из-за этого у него и иконка такая.
Только вчера поставил, уже многое посмотрел, но как-то законченное мнение пока рано говорить. Качество в целом внушает. Если прямо нет требования семантической подсветки, то наверно это лучшее, что теперь есть под линукс.
Только вчера поставил, уже многое посмотрел, но как-то законченное мнение пока рано говорить. Качество в целом внушает. Если прямо нет требования семантической подсветки, то наверно это лучшее, что теперь есть под линукс.
По этому поводу пока ничего не решили. Голосуйте в трекере.
Как альтернатива, можно воспользоваться action'ом «Highlight usages in file».
Как альтернатива, можно воспользоваться action'ом «Highlight usages in file».
Ежедневно пользуюсь CLion уже месяца три, вы как раз выкатили первый EAP незадолго до того, как я пересел на С++. Разумеется, не все во время использования было гладко, но критичные баги быстро пофиксили, а с некоторыми небольшими улучшениями и фичами можно и подождать. В целом получилась отличная система, уже запросил на работе ключи для себя и коллег. Моя оценка — десять рефакторингов из десяти. Поздравляю с долгожданным релизом!
НЛО прилетело и опубликовало эту надпись здесь
Это забота CMake.
Так как на C довольно много embedded-разработки, определённо будем думать в этом направлении.
Для Qt Creator'а я сделал так: habrahabr.ru/post/248517 (или тут: htrd.su/wiki/zhurnal/2015/01/22/cmakeprojectmanager2_uluchshenija_v_dialoge_konfigurirovanija)
Кросс-билдинг основан на стандартном механизме тулчейнов CMake. Сам тулчейн можешь написать и сохранить в проекте, для нужной конфигурации просто выбрать его или написать inline-тулчейн (рыба предлагается). Задумывал ещё на основе Kit'ов генерить, но пока времени заняться нет.
Может какие идеи пригодятся :)
Кросс-билдинг основан на стандартном механизме тулчейнов CMake. Сам тулчейн можешь написать и сохранить в проекте, для нужной конфигурации просто выбрать его или написать inline-тулчейн (рыба предлагается). Задумывал ещё на основе Kit'ов генерить, но пока времени заняться нет.
Может какие идеи пригодятся :)
Стоит ли ждать плагина к InteliJ IDEA Ultimate в ближайшее время или покупать CLion Standalone?
Ребята, я был на последнем CodeFest'е и оставил, свой e-mail JetBrains'ам на стенде. Вчера они прислали мне один скидочный купон на 20%. Если кому-то надо, пишите в личные сообщения — отправлю.
Где-нибудь можно посмотреть список поддерживаемых модулей CMake в IDE? В частности интересует ExternalProject.
Ещё бы поддержку qmake-проектов…
Реквест есть, за него можно проголосовать. В самое ближайшее время это вряд ли случится. Пока хотим закончить умную поддержку CMake. А потом уж посмотрим на другие билд-системы. Правда пока по трекеру (по количеству голосов) Makefiles лидируют)
О, спасибо, проголосую. У меня все кросс-платформенные проекты используют qmake, даже если не используют сам Qt.
Makefiles — тяжелое наследие прошлого.
Makefiles — тяжелое наследие прошлого.
Ну, кстати, если можно с помощью qmake сгенерировать make-файлы и открыть проект в CLion таким образом — почему бы и нет. Лишь бы нормально работало.
Пользуюсь CLion с первого EAP билда.
Воюем с коллегой на тему CLion+Cmake vs QTCreator+Qmake. Без удалённой отладки я разгромно проигрываю эту битву :) В трекере уже за всё нужное проголосовал.
И релизу радуюсь. Куплю на днях. Но вот каждый раз выходит новая версия и думаешь, то ли сам успел куда-то влезть и функция перестала работать, то ли погибла в процессе разработки. EAP упоминать не буду, там это нормально. А вот в релизе…
Точно помню, что в старых EAP версиях я использовал ctrl+c в консоли «Run» и сигнал благополучно уходил в программу. А теперь получаю копирование из консоли, хоть ты тресни. И теперь не знаю, это такую фичу для удобства сделали (тогда бы кнопочку какую, для отправки сигналов в программу, или возможность запустить её в полноценной консоли) или случайно отломали?
Воюем с коллегой на тему CLion+Cmake vs QTCreator+Qmake. Без удалённой отладки я разгромно проигрываю эту битву :) В трекере уже за всё нужное проголосовал.
И релизу радуюсь. Куплю на днях. Но вот каждый раз выходит новая версия и думаешь, то ли сам успел куда-то влезть и функция перестала работать, то ли погибла в процессе разработки. EAP упоминать не буду, там это нормально. А вот в релизе…
Точно помню, что в старых EAP версиях я использовал ctrl+c в консоли «Run» и сигнал благополучно уходил в программу. А теперь получаю копирование из консоли, хоть ты тресни. И теперь не знаю, это такую фичу для удобства сделали (тогда бы кнопочку какую, для отправки сигналов в программу, или возможность запустить её в полноценной консоли) или случайно отломали?
Жду плагинов для МК AVR и ARM.
Ой крутяяяк. Сердечно поздравляю Вас с релизом!
Пробовал бэту около 3х месяцев назад на небольшом проекте, много чего понравилось. Не понравилось что не стартует на LInux x32… Дома ноут старенький, железо нынче дорогое… В общем хочется…
Вот доберусь до своего проекта, обязательно куплю!
Пробовал бэту около 3х месяцев назад на небольшом проекте, много чего понравилось. Не понравилось что не стартует на LInux x32… Дома ноут старенький, железо нынче дорогое… В общем хочется…
Вот доберусь до своего проекта, обязательно куплю!
У меня на Ubuntu 14.04 (Unity) иконка отображается в очень низком качестве (будто 64х64), что в dock, что при переключении окон alt+tab. Можно что-то с этим сделать?
Всю информацию о том, какие файлы входят в проект, какой стандарт C++ стоит использовать, какие библиотеки и флаги компиляции будут использоваться, и т. д. CLion берет именно из CMake.Это с самого начала вызывало у меня недоумение. CMake, независимо от того, насколько он популярен — не краеугольный камень, а всё-таки частный случай. Почему нет возможности создать freestyle-проект, который можно самостоятельно наполнить и настроить? Взять тот же CodeBlocks — он универсален, а ваша IDE — нет. Я так долго её ждал, а в итоге банально не смог ею воспользоваться, поскольку не использую CMake в качестве системы сборки.
Не могу понять, какое это имеет отношение к моему комментарию. Я как раз предложил избежать этой проблемы и не использовать какое-либо конкретное решение в качестве единственно возможного варианта. Ну, или не ограничиваться набором конкретных поддерживаемых решений.
Почему бы не дать возможность создавать любой проект со свободной конфигурацией, командами сборки и т.п.? Это дало бы возможность вообще не зависеть от системы сборки. А CMake и т.п. вполне себе можно поддерживать дополнительно.
Почему бы не дать возможность создавать любой проект со свободной конфигурацией, командами сборки и т.п.? Это дало бы возможность вообще не зависеть от системы сборки. А CMake и т.п. вполне себе можно поддерживать дополнительно.
Благодаря чтению всей информацию из CMake файлов, мы можем зато резолвить код более корректно. При этом довольно много проектов использует CMake, поэтому начать мы решили с него.
Конечно, можно было бы попытаться сделать какой-то общий интерфейс, general, для конфигурации под любую билд систему, но, боюсь, пока мы не попробуем поддержать парочку конкретных систем, мы не поймем как этот интерфейс должен выглядеть.
Конечно, можно было бы попытаться сделать какой-то общий интерфейс, general, для конфигурации под любую билд систему, но, боюсь, пока мы не попробуем поддержать парочку конкретных систем, мы не поймем как этот интерфейс должен выглядеть.
НЛО прилетело и опубликовало эту надпись здесь
Посмотрите на существующие реализации (например, CodeBlocks). В самой простой реализации это банальный редактор конфигураций, где можно задать команды сборки проекта/отдельного файла, пути, общие настройки (типа DEFINES и т.п.) и состав проекта или маски включения. Всё остальное уже вторично.
Для *nix-овой C++-разработки в настоящий момент использую NetBeans, но нахожусь в активном поиске (все проекты на cmake). Пробовал clion где-то полгода назад, но тогда он был достаточно нестабилен (по крайней мере, были проблемы с зависаниями на моих проектах). С удовольствием поиграюсь с новым релизом.
Скажите пожалуйста, планируется ли поддержка директивы cmake source_group (виртуальные папки)? К сожалению, на сегодняшний момент единственный способ использовать виртуальные папки — это Visual Studio-генератор (но это подходит только для Windows-разработки). Все поддерживающие cmake ИДЕшки почему-то принципиально игнорируют данную директиву и используют структуру папок директории проекта.
Если не планируется (или вопрос поддержки обсуждается) — занесите в wish-list плз.
Скажите пожалуйста, планируется ли поддержка директивы cmake source_group (виртуальные папки)? К сожалению, на сегодняшний момент единственный способ использовать виртуальные папки — это Visual Studio-генератор (но это подходит только для Windows-разработки). Все поддерживающие cmake ИДЕшки почему-то принципиально игнорируют данную директиву и используют структуру папок директории проекта.
Если не планируется (или вопрос поддержки обсуждается) — занесите в wish-list плз.
папок директории проекта.
Есть такая штуку как Матрица компетентности программиста, там есть такой пункт Организация дерева исходников, в котором
Структура дерева исходного кода соответствует логической иерархии и организации кода в проекте.
Глядя на имена файлов и структуру папок, можно понять как спроектирована данная система.
Встречал такой подход в нескольких фирмах в которых работал, и это чертовски удобно, когда тебе говорят: -вон там наш старый проект, теперь ты будешь его поддерживать.
Не хочу начинать священную войну о том, как правильно организовывать структуру проекта, поэтому всё нижеследующее является моим личным имхо.
Разбивать файлы на группы можно по разным критериям. Соответственно, итоговые группы получаются разные. Разбиение с использованием директорий файловой системы даёт возможность применить только один какой-то критерий.
Впрочем, от абстракции к конкретике: где лично мне удобно использовать виртуальные папки.
Допустим, у нас есть библиотека. В ней есть публичные хедеры (.h) и исходники реализации (.cpp .h и т.д). Очевидно, публичные хедеры должны лежать в папке отдельной от исходников реализации. В то же время для редактирования удобнее видеть .cpp и соответвующий .h рядышком.
Вторая причина. Если библиотека нетривиальна, то всегда хочется группировать файлы по функционалу. Если группировать их с использованием директорий файловой системы, то становится неудобно использовать директорию include (например, в llvm вечно приходится искать, в какую подпапку они положили соответвующий хедер, особенно с учётом того что они любят тасовать файлы по папкам в каждом новом релизе). Я лично предпочитаю иметь одну большую папку include, а группировку в ней осуществлять виртуальными папками.
Впрочем, на вкус и цвет… Но подозреваю, что я не единственный любитель виртуальных папок :)
Разбивать файлы на группы можно по разным критериям. Соответственно, итоговые группы получаются разные. Разбиение с использованием директорий файловой системы даёт возможность применить только один какой-то критерий.
Впрочем, от абстракции к конкретике: где лично мне удобно использовать виртуальные папки.
Допустим, у нас есть библиотека. В ней есть публичные хедеры (.h) и исходники реализации (.cpp .h и т.д). Очевидно, публичные хедеры должны лежать в папке отдельной от исходников реализации. В то же время для редактирования удобнее видеть .cpp и соответвующий .h рядышком.
Вторая причина. Если библиотека нетривиальна, то всегда хочется группировать файлы по функционалу. Если группировать их с использованием директорий файловой системы, то становится неудобно использовать директорию include (например, в llvm вечно приходится искать, в какую подпапку они положили соответвующий хедер, особенно с учётом того что они любят тасовать файлы по папкам в каждом новом релизе). Я лично предпочитаю иметь одну большую папку include, а группировку в ней осуществлять виртуальными папками.
Впрочем, на вкус и цвет… Но подозреваю, что я не единственный любитель виртуальных папок :)
Интересное предложение. А Вы не могли занести в трекер? Нам очень поможет описание use case, как вы себе это видите в IDE и пр.
К сожалению, у меня нет аккаунта на вашем трекере. Создам чуть попозже и тогда добавлю. Как я себе вижу это в IDE — помимо File View, отображающего структуру файловой системы, должен быть какой-нибудь Source Group View, отображающий структуру виртульных папок (в качетсве reference — смотреть что создаёт Visual Studio-генератор cmake-а).
Кому надо — будут использовать для навигации виртуальные папки, кому нет — можно работать с File View, как привыкли.
Кому надо — будут использовать для навигации виртуальные папки, кому нет — можно работать с File View, как привыкли.
Вопрос может немного не в тему, но нет ли планов у JetBrains разработать IDE для программирования микроконтроллеров?
Если такое уже есть и я что-то упустил, то киньте ссылочку. Интересна разработка под STM32.
Если такое уже есть и я что-то упустил, то киньте ссылочку. Интересна разработка под STM32.
НЛО прилетело и опубликовало эту надпись здесь
Добавить к комментарию выше в общем нечего. Отдельной IDE никакой не планируем.
Можно ещё голосовать за youtrack.jetbrains.com/issue/CPP-871
Друзья, подскажите, а можно ли как-то отключить автоформатирование кода? Все излазил — не нашел.
Я, наверное, извращенец, но мне удобнее оформлять инструкции препроцессора отступами (особенно в кроссплатформенных проектах это чувствуется). Например:
А IDE постоянно съедает эти отступы.
Так же очень докучает навязчивое форматирование аргументов при вызове функций. При вот таком написании:
Творится сущий ад. А уж если вдруг нужно написать вот так:
То все, пиши пропало. Не работает ни таб, ни shift-tab, ни space. ни enter. При нажатии на любой из них код, простите за выражение, распидорашивает по самое не балуйся.
Все это сильно тормозит работу и сводит на нет плюсы IDE.
P.S.: А еще этот косяк с CMake: путь вида D:\ProgramFiles(x86)\JetBrains\CLion\bin\cmake\bin\cmake.exe нужно брать в двойные апострофы при генерации make файлов, но этого не происходит. В итоге ничего не собирается. Благо это легко решается символьной ссылкой.
Я, наверное, извращенец, но мне удобнее оформлять инструкции препроцессора отступами (особенно в кроссплатформенных проектах это чувствуется). Например:
#ifdef OS_POSIX
#define POSIX_THREAD
//тут обычный код
#else
//тут тоже код
#endif
А IDE постоянно съедает эти отступы.
Так же очень докучает навязчивое форматирование аргументов при вызове функций. При вот таком написании:
SomeVar = SomeFunction
(
LongLongArgument1,
LongLongArgument2,
LongLongArgument3
);
Творится сущий ад. А уж если вдруг нужно написать вот так:
if
(
SOME_CONST == SomeFunction
(
LongLongArgument1,
LongLongArgument2,
LongLongArgument3
)
)
{
//тут код
}
То все, пиши пропало. Не работает ни таб, ни shift-tab, ни space. ни enter. При нажатии на любой из них код, простите за выражение, распидорашивает по самое не балуйся.
Все это сильно тормозит работу и сводит на нет плюсы IDE.
P.S.: А еще этот косяк с CMake: путь вида D:\ProgramFiles(x86)\JetBrains\CLion\bin\cmake\bin\cmake.exe нужно брать в двойные апострофы при генерации make файлов, но этого не происходит. В итоге ничего не собирается. Благо это легко решается символьной ссылкой.
НЛО прилетело и опубликовало эту надпись здесь
С форматированием макросов — сейчас есть в трекере целый ряд задач, как, например, вот эта — https://youtrack.jetbrains.com/issue/CPP-2830, которая сейчас как раз в разработке.
Со вторым и третьим случаем, Вам нужны настройки Wrapping & Braces | Function call arguments. Правда '(' будет все равно сдвинута на размер continuation indent (https://youtrack.jetbrains.com/issue/CPP-1212).
Совсем отключить форматирование во всем проекте, к сожалению, не получится. Есть formatter markers, которые позволяют отключать форматирование отдельных фрагментов. Ну и, как уже было сказано, можно отключить автоформатирование при коммите (соб-но, по умолчанию оно выключено).
Про CMake — а можно Вас попросить завести ишью в трекере? Заранее спасибо.
Со вторым и третьим случаем, Вам нужны настройки Wrapping & Braces | Function call arguments. Правда '(' будет все равно сдвинута на размер continuation indent (https://youtrack.jetbrains.com/issue/CPP-1212).
Совсем отключить форматирование во всем проекте, к сожалению, не получится. Есть formatter markers, которые позволяют отключать форматирование отдельных фрагментов. Ну и, как уже было сказано, можно отключить автоформатирование при коммите (соб-но, по умолчанию оно выключено).
Про CMake — а можно Вас попросить завести ишью в трекере? Заранее спасибо.
Очень надеюсь на скорейшее решение проблем с форматированием макросов. Как только выйдет — сразу приобрету такую замечательную IDE. :)
В «Wrapping & Braces | Function call arguments» я копался, особо положение дел не меняется. А вот установка «continuation indent» в ноль более-менее помогла, спасибо. Теперь просто аргументы вручную отбиваю. Но, все же, хотелось бы иметь отдельные настройки отступов для аргументов и скобок.
А почему бы не сделать отключение форматирования во всем проекте, кстати? Думаю, иногда это было бы полезно. Особенно, если бы можно было отключать не все форматирование, а только какую-нибудь особо докучающую часть, настроек для которой пока нету/не планируется.
Ишью завел. Но в силу моих скудных знаний английского, описание кривое и короткое. :)
В «Wrapping & Braces | Function call arguments» я копался, особо положение дел не меняется. А вот установка «continuation indent» в ноль более-менее помогла, спасибо. Теперь просто аргументы вручную отбиваю. Но, все же, хотелось бы иметь отдельные настройки отступов для аргументов и скобок.
А почему бы не сделать отключение форматирования во всем проекте, кстати? Думаю, иногда это было бы полезно. Особенно, если бы можно было отключать не все форматирование, а только какую-нибудь особо докучающую часть, настроек для которой пока нету/не планируется.
Ишью завел. Но в силу моих скудных знаний английского, описание кривое и короткое. :)
Когда никогда раньше такой идеи не было) Мы подумаем, спасибо.
Сейчас есть еще функционал, когда используется indent опции самого файла, что может быть актуально, если Вы редактируете файл в какой-то сторонней библиотеке со своим собственным code style. Происходит автоматическое определение параметров и потом IDE их использует.
Сейчас есть еще функционал, когда используется indent опции самого файла, что может быть актуально, если Вы редактируете файл в какой-то сторонней библиотеке со своим собственным code style. Происходит автоматическое определение параметров и потом IDE их использует.
Было бы очень круто наличие дизассемблированного кода и сырого кода в hex для отладки
Сейчас во вкладке debug -> dbg можно вызвать disassemble funct_name и с этим даже можно работать, но форматирование страдает:
Работать можно, но удобства не хватает. Потому бы здорово получить вывод asm, register и hex в отдельных вкладках (окна), как это в других IDE. И вообще идеально было бы получить возможность отладки в asm, но это не так критично при наличии прямого доступ к gdb (с tui)
Видел в трекере тикет по теме. С другой стороны может тут будет ещё мнение по этому вопросу.
Сейчас во вкладке debug -> dbg можно вызвать disassemble funct_name и с этим даже можно работать, но форматирование страдает:
- отступы съезжают
screenshot
- подсветки нет
- поддержки tui во встроенному gdb тоже нет
Работать можно, но удобства не хватает. Потому бы здорово получить вывод asm, register и hex в отдельных вкладках (окна), как это в других IDE. И вообще идеально было бы получить возможность отладки в asm, но это не так критично при наличии прямого доступ к gdb (с tui)
Видел в трекере тикет по теме. С другой стороны может тут будет ещё мнение по этому вопросу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CLion 1.0 — мощный инструмент для мощного языка