Комментарии 68
Так а отладчик под Windows вообще планируется? Просто я не вижу особого смысла в IDE без возможности отладки.
В общем пока единственным способом кросплатформенной разработки под Windows остается Visual Studio, благо поддежка MSVC в CMake есть уже давно.
В общем пока единственным способом кросплатформенной разработки под Windows остается Visual Studio, благо поддежка MSVC в CMake есть уже давно.
В общем пока единственным способом кросплатформенной разработки под Windows остается Visual Studio
а чем плох QtCreator?
QtCreator не плох. В нём просто меньше фичей чем в Clion или VisualStudio с Visual Assist/ Re-sharper. Ну и медленно работает на больших проектах. А к хорошему быстро привыкаешь и назад на QtCreator уже не хочется.
Там отладчик вроде бы и есть, но на практике он не юзабелен, особенно, когда ничего не мешает переключиться в VS и почувствовать себя там белым человеком.
Как редактор QtCreator был бы не хуже VS (кое-что лучше сделано в одной IDE, кое-что в другой, в итоге так на так выходит), если бы нормально допилили code model. Сейчас сложилась ситуация, что родная legacy модель прекрасно быстро работает, но вообще не понимает современный С++ (auto, а порой и просто шаблоны), а clang code model работает отвратительно.
Как редактор QtCreator был бы не хуже VS (кое-что лучше сделано в одной IDE, кое-что в другой, в итоге так на так выходит), если бы нормально допилили code model. Сейчас сложилась ситуация, что родная legacy модель прекрасно быстро работает, но вообще не понимает современный С++ (auto, а порой и просто шаблоны), а clang code model работает отвратительно.
то есть код модель студии отображает те фичи, которые не поддерживает студия?
Не понял вас. Модель студии в полной мере понимает код, который компилятор студии способен скомпилировать.
это едкое замечания по поводу того, что студия 17-ого года не поддерживает половину возможностей c++17, в то время как тот же gcc реализует её в полной мере, а clang — почти полностью. Плюс, в gcc реализована спецификация концептов.
2017-м компилятором ещё не пользовался, сдерживают сторонние библиотеки. Знаю только, что этот компилятор сейчас активно разрабатывается и чуть ли не каждую неделю обновляется, так что, думаю, скоро допилят.
Против clang ничего не имею, речь была конкретно о clang code model в Qt Creator, которая неюзабельна, и это делает неюзабельной всю IDE.
Против clang ничего не имею, речь была конкретно о clang code model в Qt Creator, которая неюзабельна, и это делает неюзабельной всю IDE.
Отладка на Windows конечно же есть.
Отладчик на Windows есть, как уже заметили. Но не в случае MSVC тулчейна. Мы смотрим сейчас, какие есть варианты в этом случае. WinGDB как один из вариантов. Но вообще пока понимания нет четкого.
Вообще довольно много было запросов от пользователей именно на компилятор. Но согласна, что отладчик в случае такого тулчейна тоже важен. Думаем.
Вообще довольно много было запросов от пользователей именно на компилятор. Но согласна, что отладчик в случае такого тулчейна тоже важен. Думаем.
Осталось сделать Memory View.
Вот про это речь?
Очень порадовало обновление, раньше CLion был на нашем проекте практически непригодным к использованию из-за всяких C++14 фишек, в некоторых файлах чуть ли не каждая третья строка была подчёркнута красным. Сейчас же буквально пара мест таких осталась.
Кстати, мне показалось, что поменялся шрифт по умолчанию, мне старый больше нравился. Ну да это мелочи.
Кстати, мне показалось, что поменялся шрифт по умолчанию, мне старый больше нравился. Ну да это мелочи.
А какая ОС? не линукс случаем?
Да, он самый.
Тоже новый шрифт не нравится, очень тонкий стал, раньше был гораздо лучше, у меня ubuntu.
Там на линуксе бага закралась. Как раз в JDK нашей кастомной. Будет фикс в апдейте первом. А пока есть workaround
а зачем Clion генерирует codeblocks project file ?
Поддержка MSVC — это замечательно. Особенно, если на Linux :) :) :) :) Ибо на Windows тяжеленная IDE, работающая на Java (я достаточно работал на NetBeans, чтобы сполна насладиться быстродействием подобных IDE), особо не нужна — MSVC вполне неплохо работает в составе Visual Studio. А, учитывая наличие Community Edition, как-то вообще пропадает желание даже пробовать IDE на Java за $89 каждый год.
А вот соглашусь с последним предложением. Почему нельзя купить приложение раз и навсегда? Пусть оно даже не получает других обновлений кроме багфиксов. Допустим, мне не нужны С++17 фичи, я пишу на чистом С и мне будет достаточно того, что уже есть? Пусть оно стоит дороже, чем по подписке, но чтобы мне не мозолил глаза счётчик «до полночи осталось две минуты».
Так ведь можно же, текущая лицензия так и работает, только получаешь то приложение за которые заплатил, без обновлений.
Можно, так и работают наши лицензии. Называется это perpetual fallback. Если заплатили за год или год платите непрерывно, то такое получаете. То есть бессрочную лицензию на ту версию, с которой начался год и баг-фикс апдейты на неё. Без обновлений на следующие версии.
anastasiak2512, fogone спасибо за разъяснения.
Пожалуйста, сделайте отдельные рабочие папки для разных IDE (.idea для идеи, .clion для силиона и так далее).
Постоянно приходится придумывать костыли или открывать проект заново с удалением папки .idea (у нас в команде разработка java — jni — c++). И подскажите, есть ли баг на эту тему, а то не смог найти?
Постоянно приходится придумывать костыли или открывать проект заново с удалением папки .idea (у нас в команде разработка java — jni — c++). И подскажите, есть ли баг на эту тему, а то не смог найти?
Круто! Давно не хватало такой фичи как Find in path popup window. Также очень понравилось Catch integration and PCH.
Планируете ли вы такую же поддержку Boost.Test как и с Google Test и Catch?
Планируете ли вы такую же поддержку Boost.Test как и с Google Test и Catch?
Спасибо на добром слове. Рады, что Вам понравилось.
Boost тесты есть в планах, но видимо не ближайших (их пока не активно просили).
Boost тесты есть в планах, но видимо не ближайших (их пока не активно просили).
Раз появилась поддержка MSVC, то интересно, появится ли возможность одновременной работы с C# и C++ в одной IDE (Rider + CLion в одном флаконе)?
возможность конвертации типа переменной в autoв этом как раз особой потребности нет, быстрее «auto» напечатать, а вот в обратную сторону…
Здравствуйте, планируется ли добавление нативной системы сборки?
Поясните, пожалуйста, что имеете в виду под нативной системой сборки?
Сборка полностью внутри IDE, без необходимости использовать CMake или другую стороннюю систему.
В ближайшее время — скорее нет. Соб-но, мы рассматриваем две альтернативы на ближайшее время в контексте билд систем: какая-то другая (Makefiles?) или «никакая» (то есть проект из директории, типа как в студии json-проекты). Но в любом случае пока:
* есть пробелы в СMake поддержке, которые надо доделать, прежде чем делать что-то еще
* ресурсы команды ограничены, а есть еще другие важные задачи
* есть пробелы в СMake поддержке, которые надо доделать, прежде чем делать что-то еще
* ресурсы команды ограничены, а есть еще другие важные задачи
или «никакая» (то есть проект из директории, типа как в студии json-проекты)
Не совсем понял, можно разжевать как это работать будет?
Это возможность открывать проект из директории с сорсами, не закладываясь ни на какую билд-систему.
То есть, просто "для просмотра", без возможно собрать проект, так? А какая-нибудь навигация при этом доступна будет?
Круто, если бы не прожорливость и некоторые забавные нюансы, то цены бы не было этой IDE.
Приведу пример «забавного нюанса», что бы не быть голословным) В CLion как вы наверно знаете добавлен плагин поддержки разработки в Python. Вау, воскликнут разработчики совмещающие эти два языка в проектах! Но если они эти два языка совмещают с помощью cython — их ждет большой облом, ибо даже нет подсветки синтаксиса .pyx, хотя в PyCharm с этим все хорошо.
Приведу пример «забавного нюанса», что бы не быть голословным) В CLion как вы наверно знаете добавлен плагин поддержки разработки в Python. Вау, воскликнут разработчики совмещающие эти два языка в проектах! Но если они эти два языка совмещают с помощью cython — их ждет большой облом, ибо даже нет подсветки синтаксиса .pyx, хотя в PyCharm с этим все хорошо.
Cython пока не успели (запрос в трекере).
НЛО прилетело и опубликовало эту надпись здесь
Это сложный вопрос и задача не самая очевидная. Попытаюсь пояснить:
Ну то есть, мы планируем, но это точно не первоочередная задача. И там ещё много вопросов.
- Исторически CLion появился из AppCode, который делался как отдельная IDE по своим причинам. Поэтому сейчас, чтобы сделать плагин, нужно чуть больше усилий.
- Нам пока не очень понятно, что именно в плагин переносить — только поддержку языка или CMake тоже. Отрезать языковую поддержку от CMake сейчас не так просто. Это будет делаться, когда начнём работать над альтернативной системой сборки помимо CMake.
- Не очень понятны случаи использования кроме Андройд разработки, про которую ниже.
- Ну и про Android Studio: там C++ поддержка из CLion, но скрученная с Андройд разработкой. Нам в IDEA получается это надо у себя реализовывать. А зачем, если есть AS и она на базе IntelliJ платформы и так.
Ну то есть, мы планируем, но это точно не первоочередная задача. И там ещё много вопросов.
А появилась ли возможность удалённой компиляции/отладки?
Немного пожалуюсь, если позволите.
Очень часто виснет намертво в сложном коде. При написании кода на данном участке завис аж 4 раза.
Частенько надолго подвисает при попытке вытащить возможные входные параметры для функции. Я не ругаю, что он не может дать адекватную подсказку, ибо код люто шаблонизирован, однако хотелось бы делать такие вещи в фоновом потоке, чтобы не мешать работе.
Очень жду поддержку С++17, особенно structured bindings, так как временные переменные, вытащенные этим образом затем не видны во всё контексте функции, что выражается в подчёркивании всего кода функции. Остальное можно перетерпеть, так как подчёркивает только саму непонятную конструкцию)
Очень часто виснет намертво в сложном коде. При написании кода на данном участке завис аж 4 раза.
template <typename... Output, typename... Input, std::size_t... I>
constexpr auto apply_cast_impl(std::tuple<Input...> t, std::index_sequence<I...>)
{
return std::make_tuple(boost::lexical_cast< typename std::tuple_element<I, std::tuple<Output...> >::type >(get<I>(t))...);
}
template <typename... Output, typename... Input>
constexpr auto apply_cast(std::tuple<Input...> t)
{
return apply_cast_impl<Output...>(t, std::make_index_sequence<sizeof...(Output)>{});
}
Частенько надолго подвисает при попытке вытащить возможные входные параметры для функции. Я не ругаю, что он не может дать адекватную подсказку, ибо код люто шаблонизирован, однако хотелось бы делать такие вещи в фоновом потоке, чтобы не мешать работе.
Очень жду поддержку С++17, особенно structured bindings, так как временные переменные, вытащенные этим образом затем не видны во всё контексте функции, что выражается в подчёркивании всего кода функции. Остальное можно перетерпеть, так как подчёркивает только саму непонятную конструкцию)
Спасибо за подробный и интересный фидбек!
Посмотрела на пример — у меня не повисло вроде. Пробовала на макоси, CLion-у у меня выделено 4Гб памяти (по дефолту — 2Гб). Завела задачку поизучать. Но было бы круто, если Вы бы смогли последить за памятью. File | Settings | Appearance & Behavior | Appearance | Show memory indicator. Ну и попробовать увеличить память, если она практически вся по индикатору используется.
Посмотрела на пример — у меня не повисло вроде. Пробовала на макоси, CLion-у у меня выделено 4Гб памяти (по дефолту — 2Гб). Завела задачку поизучать. Но было бы круто, если Вы бы смогли последить за памятью. File | Settings | Appearance & Behavior | Appearance | Show memory indicator. Ну и попробовать увеличить память, если она практически вся по индикатору используется.
8 Гб выделено, когда clion намертво зависал память особо не менялась, в среднем ~1.5 Gb.
Стоит всё на ubuntu 16.04.
Кстати, когда стояла preview версия, постоянно шли ошибки по stack overflow при построении или при разборе ast, видимо нужно переписывать рекурсивные алгоритмы в тех местах, где дерево может очень большое
Стоит всё на ubuntu 16.04.
Кстати, когда стояла preview версия, постоянно шли ошибки по stack overflow при построении или при разборе ast, видимо нужно переписывать рекурсивные алгоритмы в тех местах, где дерево может очень большое
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Релиз CLion 2017.1: C++14, C++17, код на дизассемблере в отладчике, Catch, MSVC и многое другое