Почему clion требует visual studio
Так а отладчик под Windows вообще планируется? Просто я не вижу особого смысла в IDE без возможности отладки.
В общем пока единственным способом кросплатформенной разработки под Windows остается Visual Studio, благо поддежка MSVC в CMake есть уже давно.
QtCreator не плох. В нём просто меньше фичей чем в Clion или VisualStudio с Visual Assist/ Re-sharper. Ну и медленно работает на больших проектах. А к хорошему быстро привыкаешь и назад на QtCreator уже не хочется.
Там отладчик вроде бы и есть, но на практике он не юзабелен, особенно, когда ничего не мешает переключиться в VS и почувствовать себя там белым человеком.
Как редактор QtCreator был бы не хуже VS (кое-что лучше сделано в одной IDE, кое-что в другой, в итоге так на так выходит), если бы нормально допилили code model. Сейчас сложилась ситуация, что родная legacy модель прекрасно быстро работает, но вообще не понимает современный С++ (auto, а порой и просто шаблоны), а clang code model работает отвратительно.
Не понял вас. Модель студии в полной мере понимает код, который компилятор студии способен скомпилировать.
это едкое замечания по поводу того, что студия 17-ого года не поддерживает половину возможностей c++17, в то время как тот же gcc реализует её в полной мере, а clang — почти полностью. Плюс, в gcc реализована спецификация концептов.
2017-м компилятором ещё не пользовался, сдерживают сторонние библиотеки. Знаю только, что этот компилятор сейчас активно разрабатывается и чуть ли не каждую неделю обновляется, так что, думаю, скоро допилят.
Против clang ничего не имею, речь была конкретно о clang code model в Qt Creator, которая неюзабельна, и это делает неюзабельной всю IDE.
В VS2017 компилятор C++ очень неплохо улучшили: с одной стороны, выросла скорость компиляции, с другой — эффективность кода. В частности, я даже отказался от постоянного использования Intel Compiler.
Надо будет заценить, хотя сомневаюсь, что поддержка половины стандарта займет у MS меньше полугода. Пока что у нас для внутренних проектов в основном используется mingw. Что до код модели — clang'овская норм, но не для Qt проектов, т.к. она попросту не понимает дефайны Qt.
Отладчик на Windows есть, как уже заметили. Но не в случае MSVC тулчейна. Мы смотрим сейчас, какие есть варианты в этом случае. WinGDB как один из вариантов. Но вообще пока понимания нет четкого.
Вообще довольно много было запросов от пользователей именно на компилятор. Но согласна, что отладчик в случае такого тулчейна тоже важен. Думаем.
Вообще возможность собрать что-то нажав кнопку из IDE не так важна. IDE это прежде всего средство работы с кодом и gui для дебагера.
Последнее верно не для всех, как мы видим по запросам от пользователей.
К тому же, подсветка кода (читай, парсинг) может зависеть от используемого компилятора. Хочется ведь, чтобы IDE понимала и подсвечивала код так же, как это потом при компиляции будет делать компилятор.
Да, про это. Очень нужная вещь.
Только сделайте, пожалуйста, возможность иметь несколько окон Memory View, а не одно. Иногда бывает нужно просматривать память по нескольким указателям одновременно.
Очень порадовало обновление, раньше CLion был на нашем проекте практически непригодным к использованию из-за всяких C++14 фишек, в некоторых файлах чуть ли не каждая третья строка была подчёркнута красным. Сейчас же буквально пара мест таких осталась.
Кстати, мне показалось, что поменялся шрифт по умолчанию, мне старый больше нравился. Ну да это мелочи.
Там на линуксе бага закралась. Как раз в JDK нашей кастомной. Будет фикс в апдейте первом. А пока есть workaround
а зачем Clion генерирует codeblocks project file ?
Мы вызываем CMake с выводом в формате CodeBlocks, который в свою очередь разбираем/парсим, чтобы зачитать информацию о проекте. Этот формат вывода в CMake наиболее информативен для нас.
Поддержка MSVC — это замечательно. Особенно, если на Linux :) :) :) :) Ибо на Windows тяжеленная IDE, работающая на Java (я достаточно работал на NetBeans, чтобы сполна насладиться быстродействием подобных IDE), особо не нужна — MSVC вполне неплохо работает в составе Visual Studio. А, учитывая наличие Community Edition, как-то вообще пропадает желание даже пробовать IDE на Java за $89 каждый год.
А вот соглашусь с последним предложением. Почему нельзя купить приложение раз и навсегда? Пусть оно даже не получает других обновлений кроме багфиксов. Допустим, мне не нужны С++17 фичи, я пишу на чистом С и мне будет достаточно того, что уже есть? Пусть оно стоит дороже, чем по подписке, но чтобы мне не мозолил глаза счётчик «до полночи осталось две минуты».
Так ведь можно же, текущая лицензия так и работает, только получаешь то приложение за которые заплатил, без обновлений.
Можно, так и работают наши лицензии. Называется это perpetual fallback. Если заплатили за год или год платите непрерывно, то такое получаете. То есть бессрочную лицензию на ту версию, с которой начался год и баг-фикс апдейты на неё. Без обновлений на следующие версии.
Пожалуйста, сделайте отдельные рабочие папки для разных IDE (.idea для идеи, .clion для силиона и так далее).
Постоянно приходится придумывать костыли или открывать проект заново с удалением папки .idea (у нас в команде разработка java — jni — c++). И подскажите, есть ли баг на эту тему, а то не смог найти?
Мне кажется, что тикета такого не было. Но обсуждения этой проблемы ведутся. Пока нет простого решения, как разделить сеттинги, но мы думаем в этом направлении.
Круто! Давно не хватало такой фичи как Find in path popup window. Также очень понравилось Catch integration and PCH.
Планируете ли вы такую же поддержку Boost.Test как и с Google Test и Catch?
Спасибо на добром слове. Рады, что Вам понравилось.
Boost тесты есть в планах, но видимо не ближайших (их пока не активно просили).
не совсем понимаю, что вы имеете в виду? Если у меня уже есть старый код, проще нажать ctrl+Backspace, auto, чем кликать «replace with auto».
Ctrl+Backspace сотрет предыдущий токен, коих в хитровывернутом типе может быть много.
В ближайшее время — скорее нет. Соб-но, мы рассматриваем две альтернативы на ближайшее время в контексте билд систем: какая-то другая (Makefiles?) или «никакая» (то есть проект из директории, типа как в студии json-проекты). Но в любом случае пока:
* есть пробелы в СMake поддержке, которые надо доделать, прежде чем делать что-то еще
* ресурсы команды ограничены, а есть еще другие важные задачи
Не совсем понял, можно разжевать как это работать будет?
То есть, просто "для просмотра", без возможно собрать проект, так? А какая-нибудь навигация при этом доступна будет?
Нет, рассматривается именно возможность со сборкой и пр. Так например в VS есть поддержка json формата описания проекта. Это примерно оно. Описывается header search пути и пр, чтобы IDE могла понять.
Тогда я не понимаю в чём тут разница с "нативной системой сборки", как хотел erlordff, ну да ладно. (:
Так я и не говорю, что это не похоже на то, что хочется. Я как раз говорю, что рассматривают ся на первую реализацию два варианта — такое вот или Makefiles.
Круто, если бы не прожорливость и некоторые забавные нюансы, то цены бы не было этой IDE.
Приведу пример «забавного нюанса», что бы не быть голословным) В CLion как вы наверно знаете добавлен плагин поддержки разработки в Python. Вау, воскликнут разработчики совмещающие эти два языка в проектах! Но если они эти два языка совмещают с помощью cython — их ждет большой облом, ибо даже нет подсветки синтаксиса .pyx, хотя в PyCharm с этим все хорошо.
- Исторически CLion появился из AppCode, который делался как отдельная IDE по своим причинам. Поэтому сейчас, чтобы сделать плагин, нужно чуть больше усилий.
- Нам пока не очень понятно, что именно в плагин переносить — только поддержку языка или CMake тоже. Отрезать языковую поддержку от CMake сейчас не так просто. Это будет делаться, когда начнём работать над альтернативной системой сборки помимо CMake.
- Не очень понятны случаи использования кроме Андройд разработки, про которую ниже.
- Ну и про Android Studio: там C++ поддержка из CLion, но скрученная с Андройд разработкой. Нам в IDEA получается это надо у себя реализовывать. А зачем, если есть AS и она на базе IntelliJ платформы и так.
Ну то есть, мы планируем, но это точно не первоочередная задача. И там ещё много вопросов.
Удаленная отладка в случае использования GDB/gdb server есть уже пару релизов как. Удаленной компиляции пока нет.
Немного пожалуюсь, если позволите.
Очень часто виснет намертво в сложном коде. При написании кода на данном участке завис аж 4 раза.
Частенько надолго подвисает при попытке вытащить возможные входные параметры для функции. Я не ругаю, что он не может дать адекватную подсказку, ибо код люто шаблонизирован, однако хотелось бы делать такие вещи в фоновом потоке, чтобы не мешать работе.
Очень жду поддержку С++17, особенно structured bindings, так как временные переменные, вытащенные этим образом затем не видны во всё контексте функции, что выражается в подчёркивании всего кода функции. Остальное можно перетерпеть, так как подчёркивает только саму непонятную конструкцию)
Спасибо за подробный и интересный фидбек!
Посмотрела на пример — у меня не повисло вроде. Пробовала на макоси, CLion-у у меня выделено 4Гб памяти (по дефолту — 2Гб). Завела задачку поизучать. Но было бы круто, если Вы бы смогли последить за памятью. File | Settings | Appearance & Behavior | Appearance | Show memory indicator. Ну и попробовать увеличить память, если она практически вся по индикатору используется.
8 Гб выделено, когда clion намертво зависал память особо не менялась, в среднем ~1.5 Gb.
Стоит всё на ubuntu 16.04.
Кстати, когда стояла preview версия, постоянно шли ошибки по stack overflow при построении или при разборе ast, видимо нужно переписывать рекурсивные алгоритмы в тех местах, где дерево может очень большое
А можно вас попросить в тикет thread dumps & логи положить. Если был фриз, IDE автоматически thread dumps генерирует. Лежат в Help | Show Logs
Посмотрела, 71 папка threadDumps-freeze. Вам любой подойдёт? Просто уже не вспомню по дате, какой относился к вышеприведённому коду
On Windows, CLion toolchains include the build tool, C and C++ compilers, debugger executable, and the environment. You can select one of the pre-defined toolchain setups (MinGW, Cygwin, Microsoft Visual C++, or WSL), Remote Host, Docker) or configure a custom toolchain (System):
Watch this video for an overview of Windows toolchain options:
If you don't need to configure custom tools or don't want to install additional software on your system, stick to MinGW (default) as it works out-of-the-box using the MinGW toolset bundled in CLion.
For details on Remote Host toolchains, see Full Remote Mode. If you are working with a Docker container, see Docker toolchain.
MinGW
CLion bundles a version of the MinGW toolset for quick setup. The exact version bundled is MinGW-w64 9.0 with languages=c,c++ , posix threads, and seh exceptions. You can use this bundled toolchain or switch to a custom MinGW installation.
Install MinGW (optional)
Download and run the MinGW-w64 installer. It provides both 64- and 32-bit options.
In the MinGW-w64 installation wizard, make sure to select the required architecture. Note that the default suggested option is 32-bit.
Wait for installation to finish.
Although MinGW-w64 provides both 64- and 32-bit options, you can also install MinGW, the 32-bit-only version.
In the MinGW installation wizard, select the following packages from the Basic Setup list: mingw-developer-tool , mingw32-base , mingw32-gcc-g++ , mingw32-msys-base .
Wait for installation to finish.
Configure a MinGW toolchain
Go to File | Settings | Build, Execution, Deployment | Toolchains .
Click and select MinGW to add a new MinGW toolchain.
In the Toolset field, you will see Bundled MinGW , which is the default option. If required, open the field to select from the list of other available installations:
Wait until the tools detection finishes.
Select the Debugger : you can use either bundled GDB, your MinGW GDB, or a custom GDB binary.
The recommended option is bundled GDB, since it is guaranteed to include Python support required for CLion data renderers.
Click Apply when all the tools are set correctly.
When using a custom MinGW installation, if CLion cannot detect the compilers, double-check the installed packages in MinGW Installation Manager .
Cygwin
Download the Cygwin installer, version 2.8 or later.
To select a package, type its name in the Search field and set the version in the New column:
Once the installation is finished, open CLion and go to File | Settings | Build, Execution, Deployment | Toolchains .
Click and select Cygwin to add a new Cygwin toolchain.
CLion will attempt to detect the Cygwin installation automatically. Check the Toolset field, and specify the path manually if required.
Wait until the tools detection finishes, and click Apply .
Windows Subsystem for Linux
You can use WSL, Windows Subsystem for Linux, as your working environment in CLion on Windows 10 (starting the Fall Creators Update version 1709, build 16299.15).
WSL toolchain enables you to build projects using CMake and compilers from Linux and run/debug on WSL without leavCLionLion running on your Windows machine.
Refer to our WSL guide for details on setting up WSL on your system and configuring WSL toolchainsCLionLion.
Microsoft Visual C++
Install Visual Studio 2013, 2015, 2017, 2019, or 2022 on your system.
In CLion, go to File | Settings | Build, Execution, Deployment | Toolchains .
Click and select Visual Studio from the list of toolchain templates.
Check the Toolset field. CLion will attempt to automatically detect the installed Visual Studio distribution. If the detection fails, set the path to Visual Studio manually.
If required, specify the Architecture ( x86 , amd64 , x86_arm , or another), Platform ( store , uwp , onecore , or leave it blank), and Version . To build your project for the selected architecture, CLion will call the script to configure the environment with the specified parameters.
If the version of your compiler toolset is earlier than the version of your Visual Studio installation, pass it in the Version field via the vcvars_ver flag, for example, -vcvars_ver=14.16 .
Wait until the tools detection is finished:
MSVC compiler
CLion supports the Microsoft Visual C++ compiler that ships with Visual Studio 2013, 2015, 2017, and 2019.
Note that msbuild is not supported: CLion runs CMake with the NMAKE generator instead.
__uuidof , __forceinline , __unaligned , and __alignof keywords;
pointer type attributes: __ptr32 , __ptr64 , __uptr , __sptr ;
MSVC built-in data types: (unsigned) __int8 , (unsigned) __int16 , (unsigned) __int32 , (unsigned) __int64 , __wchar_t ;
additional format specifiers, such as %I32 and %I64 ;
the clang's -fms-extensions flag.
Clang-cl compiler
As an alternative compiler, you can use clang-cl - the MSVC-compatible compiler driver for Clang. CLion supports clang-cl version 8.0 and later.
Install clang-cl from the LLVM site or along with the Visual Studio tools.
When installed from the LLVM site, the clang-cl binary can be found at the standard location C:\Program Files\LLVM\bin\clang-cl.exe for the 64-bit version or C:\Program Files (x86)\LLVM\bin\clang-cl.exe for the 32-bit version.
In CLion, go to File | Settings | Build, Execution, Deployment | Toolchains and select the Visual Studio toolchain that you want to configure, or create a new one.
Point the C Compiler and C++ Compiler fields to clang-cl.exe . CLion will suggest the paths detected automatically.
Note that currently the -T clangcl options can't be picked up if the bundled CMake is in use along with the Visual Studio toolchain setup (CPP-18848).
MSVC debugger
The MSVC toolchain debugger is implemented on top of LLDB, and it can work with native visualizers from the Visual Studio installation or from your project.
To enable native visualizers support and set the desired diagnostics level, select the Enable NatVis renderers for LLDB checkbox in Settings | Build, Execution, Deployment | Debugger | Data Views | C/C++ :
CLion automatically generates one-line summaries for all structures not covered by Natvis and highlights them to increase readability. Also, the built-in formatters provide visualization for wide/Unicode strings ( wchar_t , char16_t , char32_t ).
If you have custom native visualizers in your project, CLion will use them as well.
System toolchain
The System toolchain on Windows allows configuring the build tool, compilers, and debugger without selecting a predefined toolset or environment, similarly to Linux and macOS. Use this toolchain option for embedded development cases like using ARM or for other custom setups.
Go to File | Settings | Build, Execution, Deployment | Toolchains .
Click and select System to add a new System toolchain.
Configure the tools and provide an environment script if required:
Initializing the toolchain environment via a script
You can point CLion to the script that initializes the environment for your project without the need to set the variables manually. This is helpful, for example, when you need to initialize compiler variables, add custom ones, or modify the PATH .
Specifying an environment script is available for all toolchains. However, it is not supported for CMake presets at the moment (CPP-26576).
Environment sourcing will happen on the first actual usage of the toolchain in a CMake profile or upon loading a Makefile project.
In the toolchain settings, click Add environment , then click From file :
In the Environment file field, specify the path to the script:
You will get notifications in case of script loading issues. CLion also checks the script loading time and terminates the execution if it takes too long.
Clang compiler on Windows
With CMake 3.15, it has become possible to use the Clang compiler on Windows with the MinGW-w64/MinGW toolchain.
However, the LLVM Clang for Windows is built using Microsoft Visual Studio, and all the built-in macros and include search paths are set up for use with Visual Studio. So if you take Clang from the LLVM repository, it will not work correctly when configured with the MinGW toolchain. One of the possible workarounds is described below.
Set up the Clang compiler for MinGW
Download the following packages with the pacman tool (use the pacman -S package_name command):
This way, you will get the Clang compiler which is built with mingw-w64 and has paths and macros that correspond to this toolchain.
Go to Settings / Preferences | Build, Execution, Deployment | Toolchains , create a MinGW toolchain, and set up the tools from MSYS.
After specifying the Toolset , check the automatically detected tools and make sure to switch to Clang in the C Compiler and C++ Compiler fields.
With this new toolchain configured, you can build the project and start using the Clang's advances tools, such as profile-guided optimization. Take a look at our detailed blogpost for instructions.
GDB on Windows
In the case of MinGW, CLion includes the bundled GDB (version 11.1). For Cygwin, you need to install the GDB package in the Cygwin Package Manager, as described in the Cygwin section of this guide.
You can also switch to a custom GDB binary. In this case, the supported GDB versions are 7.8.x-11.1.
Note that for GDB 8.0 and later, debugger output is redirected to CLion console by default. To enable opening an external console window for application input/output, go to Help | Find Action or press Ctrl+Shift+A , search for Registry , and set the following key: cidr.debugger.gdb.workaround.windows.forceExternalConsole .
Лето за окном пролетает для нас почти незаметно, потому что все эти месяцы мы посвятили работе над новым релизом 2019.2 нашей кросс-платформенной среды для разработки на C++ — CLion. Мы успели довольно много всего: и провести внутренний Хакатон, и попробовать новые идеи, и довести ряд исправлений и новых возможностей до непосредственного релиза. Но обо всем по порядку.
Если коротко, то в этом релизе мы:
- Продолжили дорабатывать поддержку разработки встроенных систем: появились новые возможности отладки и просмотр периферии.
- Довели до приемлемого качества пока что экспериментальный отладчик для MSVC.
- Полностью переписали на clangd проверку кода на Unused Includes, добавив возможность настраивать разные стратегии.
- Реализовали подсказки для аргументов вызова функций и лямбд, чтобы улучшить читаемость кода.
- Провели внутрикомандный Хакатон по улучшению производительности, придумали кучу новых подходов и успели воплотить в жизнь несколько улучшений.
- Реализовали подсветку синтаксиса более чем для 20 языков, встроили плагин для написания скриптов (Shell Script plugin), обновили плагин для Rust.
Новые возможности для встроенной разработки
В прошлом релизе почему-то многим показалось, что мы сфокусированы только на STM32-платах. Это, конечно, по многим исследованиям (включая наше внутреннее) один из наиболее интересных и обширных рынков, но мы сейчас пытаемся решать и более общие задачи. Вот, например, расширили возможности отладки на различных платах из CLion.
Раньше единственной возможностью была конфигурация для отладчика OpenOCD — OpenOCD Download & Run. Теперь появилась еще одна — Embedded GDB Server. По сути, если плата поддерживает отладку через какой-либо совместимый сервер GDB, вы сможете отлаживать на ней через CLion. Конфигурация покрывает такие случаи, как OpenOCD, ST-Link GDB Servers, Segger J-Link GDB Server, QEMU и не только.
Достаточно создать и настроить соответствующую конфигурацию — указать путь до сервера GDB, аргументы, которые ему передать, возможно, какие-то более продвинутые настройки. Теперь запускайте отладку в данной конфигурации, и можно отлаживать на плате прямо из CLion!
Есть одно важное ограничение, которое действует сейчас на обе конфигурации для отладки встроенных систем, — они обе пока что работают только с проектами на CMake. В будущем мы планируем добавить возможность запускать их для кастомных проектных моделей (CPP-16079).
Для обеих существующих теперь конфигураций отладки встроенных систем (Embedded GDB Server и OpenOCD Download & Run) в новом релизе появилась возможность просмотра периферии при отладки. В целом, периферия специфицирована для устройств семейства ARM, в файлах формата .svd. Именно эти спецификации можно теперь подгрузить в CLion и просматривать выбранную периферию прямо в окне отладчика:
Вся периферия пока доступна в режиме только чтения, при этом есть поиск по названиям, возможность просматривать значения в разных режимах (шестнадцатеричном, десятичном, восьмеричном и бинарном). Чуть подробнее про это можно почитать в нашем блоге (на английском).
Экспериментальный отладчик для MSVC
Вы все правильно прочитали — в релизе 2019.2 в CLion появился экспериментальный отладчик для кода, скомпилированного с помощью MSVC! Теперь давайте разбираться чуть более детально и по порядку.
Уже давно в CLion можно при разработке на платформе Windows использовать не только тулчейн MinGW и Cygwin, но и Visual Studio. Вы указываете в CLion путь до установленной VS, а мы оттуда берем компилятор MSVC и скрипты для настройки окружения. Но вот с отладчиком долгое время были проблемы. Дело в том, что тот отладчик, который использует сама Visual Studio, проприетарный. Проще говоря, нигде, кроме инструментов Microsoft, его по лицензии использовать нельзя. Есть альтернативная технология — dbgeng.dll, на которой реализованы отладчики CDB и WinGDB. Мы первым делом опробовали ее. Но нам показалось, что бороться с количеством критических падений и плохой производительностью на бинарниках с больших количеством PDB-файлов не очень перспективно (хотя мы поначалу пытались). И тут выяснилось, что есть третий вариант — реализовать отладчик поверх LLDB. Там уже были наработки, и нам оставалось только продолжить эту работу. Что мы и сделали! Кстати, основные наши изменения (кроме пока что поддержки нативных визуализаторов данных) мы все положили в мастер LLVM.
Как включить? Как я уже писала, возможность пока экспериментальная. Отладчик еще рано называть полноценным, в нем множество ограничений и недоделок, да и производительность требует значительных оптимизаций. Эта экспериментальная возможность включается в диалоге Maintenance ( Shift+Ctrl+Alt+/ на Linux/Windows, ⌥⇧⌘/ на macOS) | Experimental features | cidr.debugger.lldb.windows. Теперь для тулчейна Visual Studio доступен новый отладчик:
Если вы планируете попробовать новый экспериментальный отладчик, рекомендуем ознакомиться со списком известных ограничений и проблем в нашем блоге.
Другие улучшения в отладчике
- Во встроенной консоли GDB/LLDB в окне отладчика в CLion теперь работает автодополнение команд самого отладчика (используйте Tab или Ctrl+Space ).
- Строковые точки останова теперь валидируются на лету, и их статус обновляется и показывается пользователю в виде соответствующей иконки. Самым интересным типом является Invalid, который был добавлен, чтобы идентифицировать те точки останова, которые не доступны в текущем исполняемом коде или для которых отсутствуют отладочные символы (в этом случае после их подгрузки статус точки останова автоматически обновится):
- При просмотре памяти в отладчике (Memory View) в новой версии появилась возможность перейти на произвольный адрес (по числовому адресу или имени/адресу переменной), а также представление памяти в формате ASCII:
Улучшения в редакторе кода
В этой области больших улучшений сразу несколько. Во-первых, мы полностью переписали проверку кода Unused Includes и включили ее по умолчанию. Раньше она тоже была, но давала большое количество ложных срабатываний, поэтому мы выключили ее по умолчанию. Почему же стало лучше? Мы полностью переписали проверку на базе второго дополнительного инструмента для парсинга кода, который, в свою очередь, основан на Clangd. Так что отсюда понятное ограничение — работать новая версия будет, только если Clangd у вас не отключен (по умолчанию он включен). Зато теперь в проверке на Unused Includes появилось несколько стратегий, между которыми можно выбирать:
По умолчанию используется Detect not directly used, которая по сути наиболее близка к известному принципу Include What You Use, то есть, если декларации из заголовочного файла не используются в данном файле напрямую, то такой заголовочный файл помечается как неиспользуемый.
С прошлого релиза CLion поддерживает ClangFormat как альтернативный инструмент форматирования кода, в дополнение ко встроенному. В этой версии мы добавили встроенную схему JSON для конфигурационных файлов .clang-format. И благодаря этому сумели добавить несколько возможностей, которые могут быть полезны тем, кто будет изменять файлы .clang-format в CLion:
- Появилось автодополнение для опций и их значений.
- В окне автодополнения для опций присутствует теперь описание опций.
- Окно документации Quick Documentation ( Ctrl+Q на Windows/Linux, F1 на macOS) показывает документацию на опции и их значения, с примерами.
- Добавлена проверка значений опций на допустимые.
Подсказки для аргументов
Что делать, если функция написана (возможно, не вами) так, что в качестве аргументов ей передается 3 целых числа? Как понять по вызову функции, что же значат передаваемые значения? Конечно, можно посмотреть сигнатуру функции в окне документации, перейти на определение функции или вызвать информацию о параметрах (Parameter Info). А если не делать этих явных действий?
В версии CLion 2019.2 появились подсказки для аргументов — при вызове функции, лямбды, конструктора, списка инициализаций или при использовании макроса CLion показывает имена параметров перед переданными аргументами:
Подсказки показываются в тех случаях, когда действительно сложно понять, какие значения каким параметрам передаются, а именно, в случае использования в качестве аргументов вызова литералов или выражений более чем с одним операндом. Подробнее в блогпосте.
Производительность
Конечно, нас часто спрашивают про улучшения производительности. Я повторюсь, для нас это наиболее приоритетная задача, но точечных изменений получается сделать не много, а глобальные требуют времени больше, чем 1-2 релизных цикла. Сейчас в работе несколько таких больших изменений. В основном, они связаны с тем, как парсер в CLion взаимодействует с архитектурой платформы (которая не всегда рассчитывает, что за простым действием, в случае C++, скрывается долгий резолв кода).
Этим летом мы с командой решили провести внутренний Хакатон, чтобы определить наиболее уязвимые места в архитектуре CLion и платформы, попробовать новые смелые идеи и проверить некоторые давние гипотезы. Результаты нам понравились. По возможности, мы планируем довести какие-то новые идеи до релиза уже к 2019.3.
Но и релиз 2019.2 не остался без улучшений производительности:
- Мы избавились от многих замедлений и зависаний в рефакторинге In-place Rename.
- Улучшена производительность автодополнения для квалифицированных выражений.
- В случае удаленной работы, мы уменьшили количество операций ввода/вывода, чем значительно ускорили сбор информации о компиляторе, а, значит, и скорость загрузки проекта CMake.
- И другие улучшения.
Не только C++
Из платформы IntelliJ в CLion 2019.2 перешло множество улучшений для работы с другими языками.
Подсветка синтаксиса более 20 языков теперь обеспечивается за счет грамматик TextMate (полный список языков можно найти в Settings/Preferences | Editor | TextMate Bundles). Конечно, если для данного языка есть расширенная поддержка в CLion (Python, JavaScript, HTML, Objective-C, SQL), то она и будет использоваться, но для таких языков, как например, Ruby, может быть полезна и простейшая подсветка:
Часто в проектах на C++ встречаются разнообразные скрипты. Плагин для поддержки написания скриптов (Shell Script plugin) теперь встроен в CLion. Он обеспечивает не только подсветку кода, но и автодополнение и текстовое переименование:
Плагин для языка Rust получил множество полезных обновлений. От нового экспериментального инструмента для раскрытия макросов (Settings/Preferences | Languages & Frameworks | Rust | Expand declarative macros) до проверки на Duplicate code fragments, различных новых быстрых исправлений (quick-fixes) и автодополнения в отладчике в Evaluate Expressions. Кстати, именно в CLion сейчас наибольшее использование данного плагина среди всех IDE от JetBrains!
Традиционный ролик о новых возможностях CLion 2019.2 (на английском):
На этом всё на этот раз. Спасибо, что дочитали до конца! Вопросы, пожелания, баг-репорты и просто мысли высказывайте в комментариях! Мы, как и всегда, будем рады ответить.
Ваша команда JetBrains CLion
The Drive to Develop
Привет, Хабр! Спешим поделиться радостной новостью – мы выпустили первый в этом году релиз нашей кросс-платформенной IDE для C и C++, CLion 2017.1!
Наши планы, как обычно, немного превосходят наши возможности и ресурсы. Но в этот релиз нам удалось успеть почти все из запланированного. Если вкратце:
- Поддержка C++14 (всё кроме constexpr)
- Начальная поддержка C++17 (мы начали с самой востребованной возможности – nested namespaces)
- Возможность конвертировать тип переменной в auto
- Во время отладки программы, при отсутствии файлов с исходным кодом можно переходить на код на дизассемблере (disassembly view)
- Поддержка фреймворка для юнит-тестирования Catch
- Значительное ускорение отклика редактора при печати кода (Zero Latency Typing)
- И, наконец, экспериментальная поддержка компилятора Microsoft Visual C++!
Кстати, попробовать все новые возможности можно на небольшом демо-проекте, который мы специально подготовили для этих целей.
C++14 и C++17
Уже совсем скоро стандарт C++17 будет официально принят и C++ сообщество примется активно обсуждать и строить планы на C++19/20. Поэтому в версии 2017.1 мы постарались полностью поддержать все текущие (и официально принятые) стандарты современного C++.
Сначала мы закончили с constexpr из C++11, а затем принялись за C++14, а именно поддержали следующие возможности:
- auto return type,
- generic lambdas,
- variable templates, and
- generalized lambda captures.
Типичный пример – использование generalized lambda captures, которое раньше приводило к тому, что весь код лямбды некорректно подсвечивался как неиспользуемый. Теперь, как видите, все хорошо:
Еще один пример – это использование auto для возвращаемого типа. В предыдущих версиях CLion не мог корректно вывести тип переменной vec , а значит и предложить корректное автодополнение:
Таким образом, из непокрытых возможностей стандарта C++14 остался только constexpr. И уже начата работа в направлении C++17: поддержаны nested namespaces. Полный список поддерживаемых в CLion возможностей современных стандартов C++ можно найти по ссылке.
Make auto
Работа в этом направлении только началась, и идей у нас много. А пока что мы добавили возможность конвертации типа переменной в auto:
Обратная замена тоже может быть реализована и даже есть в планах (CPP-8555).
Precompiled headers (PCH) – это общепринятый способ сэкономить на времени компиляции, если в проекте используются большие заголовочные файлы или просто какой-то набор таких файлов используется очень часто. Притом эти файлы меняются редко. В такой ситуации есть смысл скомпилировать их единожды и в дальнейшем просить компилятор переиспользовать имеющуюся информацию.
В такой ситуации IDE должна разобраться, какие PCH передаются при компиляции, найти их и прочитать символы из этих заголовочных файлов, которые могут понадобиться для основного кода проекта.
Теперь CLion так умеет. Относится это как к PCH, так и к заголовочным файлам, передаваемым через опцию компиляции -include. То есть соответствующие классы, функции, и т. п. из таких заголовочных файлов корректно понимаются:
Обратите внимание, что для GCC есть небольшие ограничения, связанные с техническими особенностями реализации.
Дизассемблирование в отладчике
Один из самых популярных запросов в нашем трекере – возможность показа ассемблерного кода при отладке. В версии 2017.1 мы реализовали две важные возможности, связанные с этим запросом:
- Подсветка синтаксиса кода на Ассемблере в редакторе (работает только для диалекта AT&T) для файлов с расширением .s и .asm, или любых других, сконфигурированных в Settings | Editor | File Types | Assembly Language.
- Показ кода на дизассемблере (disassembly view) во время отладки при переходе на вызов, для которого нет исходных текстов программы.
Работает disassembly view пока только для GDB. По коду на дизассемблере можно походить, чтобы лучше понять, что именно делает программа и, возможно, найти проблему, ради которой и запускался отладчик. Поставить точки останова в таком коде пока нельзя.
На будущее запланирована возможность показа кода на дизассемблере даже в том случае, когда исходные коды программы имеются (CPP-9091).
Catch
Для C++ существует огромное множество тестовых фреймворков: Google Test, CppUnit, CppTest, Boost, QtTest и другие. CLion поддерживает Google Test уже довольно давно. А в версии 2017.1 появилась поддержка Catch. Почему именно Catch?
- Catch очень легко начать использовать. Чтобы подключить Catch к своему проекту, достаточно скачать и добавить в проект один единственный заголовочный файл. Удобно, не правда ли?
- Тест-кейсы в Catch достаточно гибкие и удобные.
- Автор фреймворка Catch, Phil Nash, с осени прошлого года работает с нами в компании JetBrains в роли девелопер-адвоката C++ продуктов компании. Так что параллельно с поддержкой Catch в CLion дорабатывался и сам фреймворк. Что, конечно, существенно помогло разработке.
Помимо удобного представления результатов, в этом окне можно:
Подробнее об особенностях и преимуществах Catch и его интеграции в CLion можно почитать в нашем англоязычном блоге.
Компилятор Microsoft Visual C++
Вероятно, одна из самых интересных возможностей этой версии. По-крайней мере, для пользователей на Windows. Дело в том, что раньше CLion работал только с GCC/Clang и на Windows приходилось устанавливать MinGW, MinGW-w64 или Cygwin. А они, в свою очередь, не всегда легко и понятно конфигурируются при установке, да и имеют ряд неудобств в целом. Так что пользователи на Windows вполне резонно просили нас поддержать компилятор Microsoft Visual C++. Что мы и сделали в 2017.1, правда пока в экспериментальном режиме.
Чтобы попробовать, надо включить соответствующую опцию в Registry:
- Откройте диалог Find Action ( Shift+Ctrl+A на Linux/Windows, ⇧⌘A на macOS)
- Введите Registry
- Выберите и откройте редактор Registry
- Начните вводить clion.enable.msvc – CLion найдет подходящую опцию в списке
- Включайте и пользуйтесь MSVC!
Теперь в настройках тулчейнов у вас появится возможность выбрать компилятор Microsoft Visual C++:
Поддерживаемые версии Visual Studio – 2013, 2015, 2017 – находятся и определяются автоматически.
Тут стоит оговориться, что работает MSVC по-прежнему через CMake (в качестве генератора в котором используется NMake вместе обычных Makefiles). То есть msbuild не поддержан. CLion предоставляет настройки архитектуры, платформы и версии в Build, Execution, Deployment | CMake:
Из важных ограничений стоит еще отметить: отсутствие отладчика и отсутствие поддержки специфических расширений языка от Microsoft. В остальном, мы будем рады, если те, кто был заинтересован в поддержке компилятора Microsoft Visual C++, попробуют его и поделятся с нами своими отзывами.
Zero-latency typing
Про zero-latency typing рассказывать можно довольно долго. Но мы лучше предложим читателям ознакомится с детальным исследованием этого вопроса от нашего коллеги.
В версии 2017.1 по умолчанию включили соответствующий режим, который до этого (в течение полугода) был в тестовом режиме. Само же решение позволяет уменьшить количество перерисовок редактора, тем самым уменьшая задержку между непосредственно печатью кода и его отрисовкой на экране.
Плагины
Версия CLion 2017.1 включает в себя полезные обновления таких плагинов как Swift, Go, Settings Repository и не только.
Если говорить про Swift, то на изменения стоит обратить внимание тем, кто использует или планирует использовать CLion в качестве Swift IDE на Linux. Благодаря команде AppCode в плагине появились новые возможности:
- шаблон для создания нового Swift проекта, с предварительно заполненным файлом CMake и Package.swift;
- ошибки, предупреждения и возможные исправления от анализатора кода на основе SourceKit;
- возможность генерации типа переменной уже после ее использования.
Изменения Go плагина были направлены на приведение его в соответствие с Gogland, отдельно стоящей IDE на базе платформы IntelliJ для этого языка.
А плагин для хранения настроек IDE в репозитории, наконец, был “забандлен” в саму IDE.
И многое другое
В версии 2017.1 произошло еще немало других изменений. Так, например, Find in Path (текстовый поиск по проекту или любому выбранному скоупу) доступен в виде popup-окна с удобным предпросмотром результата:
А в окне логов от системы контроля версий (для Git и Mercurial) появилась возможность использовать регулярные выражения и выбирать учитывать ли или наоборот игнорировать регистр.
Вот здесь небольшая демонстрация новых возможностей CLion 2017.1:
Если вам стало интересно, качайте 30-дневную бесплатную пробную версию, а в разделе цен можно узнать о стоимости подписки.
Следите также за статьями и обновлениями в нашем англоязычном блоге. Мы будем рады ответить на любые ваши вопросы в комментариях.
Это статья всего лишь нагромождение моего опыта и попыток подключения малоизвестного компилятора к IDE общего назначения, она не является руководством КАК СДЕЛАТЬ, скорее для помощи и экономии времени тех, кто имеет схожие цели.
Описываемый процесс написан чайником и предназначен для совсем чайников, может иметь имеет неточности, ошибки, использование магии и прямое вранье во имя упрощения. Если вам интересно как это действительно правильно работает и что под капотом — перепроверяйте и читайте официальные гайды.
Тут будет много «не знаю как это работает, но я так сделал и оно заработало».
Интро или «Нахрена?»
К тому же многие IDE любят использовать собственную неведомую генерацию makefile и при желании хоть как то автоматизировать сборку дают 2 варианта: поддерживать 2 независимых (для IDE и внешнюю) описания сборки, либо прирастать к мейкфалу генерируемому самой IDE. Про сборку через CMake обычно даже слышать не приходиться.
Последней каплей наверно стало, когда выкупивший Atmel Microchip отказался от поддержки Atmel Studio 7, являющийся наверно самой адекватной из всего зоопарка «микроконтроллерных IDE» и стал переводить все на свою богомерзкую MPLABX полную багов, тормозов и прочего говна.
- Восприятие внешней системы сборки без костылей и ее полная интеграция.
- Отображение ошибок синтаксиса и сборки с свистелками и перделками.
- Рабочая и не тормозящая проверка синтаксиса.
- Рабочее и не тормозящее автодополнение, с зайчатками разума.
- Отсутствие битых зависимостей и заголовочников.
- Хотя бы какой-то контроль стиля кода.
Кандидаты
Я к своему стыду являюсь заядлым виндузятником и не могу без боли и отвращения братского понимания воспринимать линуксовские GUI, а потому, когда Eclipse отказался перемещать текстовый курсор при ПКМ, я его удалил, закончив свое знакомство на 5й минуте.
После быстрого поиска, стало ясно, что само сообщество С\С++ программистов судя по всему не особо нуждается в чем то подобном, а мои требования скорее «изнеженный каприз» презираемый опытным боевыми кодерами, хреначащими 3 каста массива указателей функций с вызовом в одну строку.
Человек не смог выйти из VIM, узнай что с ним стало.
- Visual Studio — лучший вариант и моя мечта. Не осилил, CMake проект завелся и собрался, но с кучей ошибок и потерянных зависимостей в самом редакторе. Добиться чего-либо от офф поддержки невозможно. Обещают в 2022 качественный завоз поддержки эмбеддед, но пока все очень не понятно и криво. Гуглятся какие-то официальные стать, где для VCPKG, VCPKG И ГОТОВО!
- VisualGDB for Visual Studio — плагин, который хочет денег, магически делает все хорошо, но завязывает вас на себе и на собственной структуре проекта с разбиением *.h и *.с файлов в разных папках, делает полную реконфигурацию проекта по каждому чиху, что на проекте из 100-200 файлов может занимать минуты, дико тормозит и любит ломаться. Пробовал еще давно — ну нахрен.
- Visual Studio Code — успех, но ввиду жабс родословной, отказался ввиду того, что не умеет искать ошибки в закрытых файлах, не умеет в вменяемый docking и самое важное — не умеет refactoring-rename между файлам, что и поставило жирный крест.
- CLion — успех, но просит денех. Несмотря на платность, имеет на мой взгляд кучу недостатков, например так же не умеет в полноценное второе окно и docking всяких радостей в него.
- QT Creator — так и не заставил себя попробовать. ПТСР от эклипса еще очень свежо.
Пререквизиты
- Установленные и работающие из под консольки система автоматизации сборки CMake и собственно система сборки Ninja
- Ваш компилятор, который успешно вызывается в консольки без указания пути, а значит внесенный в системную переменную PATH
И CMake файл, с простейшими указаниями.
Внимание к cmake_minimum_required(VERSION 3.20), у меня при версии выше 3.21 выдавались очень не понятные ошибки, слабо указывающие на зависимость от этого параметра. Может «шарящим» людям ясно из-за чего, но для меня это магия, в которую я пока не погружался.
set(CMAKE_TOOLCHAIN_FILE external/cmake-microchip/toolchain.cmake)
Это магическая переменная CMake, куда загружен относительный путь к моему Toolchain файлу.
set(MICROCHIP_MCU PIC18F97J60) Определение процессора, для которого производится сборка. Это требует конкретно мой тулчейн.
Все это дело, я собираю из консоли простейшими командами.
- cmake -S ./ -B ./build -G «Ninja» инициализация CMake (не спрашиваете, что это, я не знаю)
- "-S ./" относительный путь к файлу CMakeLists.txt, который в моем случае находится в корне проекта.
- "-B ./build" относительный путь к директории, куда будет произведена инициализация CMake.
- "-G «Ninja» указание генератора, модные хипстеры говорят мейкфайл говно, а ninja круто, так что выберем этот симплдимпл.
- «ninja -C ./build» запуск сборки, где "-C ./build" путь к директории с сгенерированными файлами.
На этом мы имеем проект, собирающийся из консоли. Который будет использован как базовый, для подключения к различным IDE.
Visual Studio Code
- C/C++ for Visual Studio Code от Microsoft
- CMake Tools от Microsoft
И так, первым делом, надо Open folder. корень проекта, после чего Save workspace as . , что создаст файл воркспейса.
Во время открытия, студия будет спамить всплывающими окнами, в том числе предлагая сконфигурировать проект под CMake — отказывается или игнорим. У меня такая штука сломала все труды и я так не разобрался почему, потратив несколько часов, закончившиеся очищением того, что оно добавило в конфиг.
После чего можно оглядеть проект из IDE.
Глядя в окно output, можно увидеть, что CMakeLists.txt автоматически подцепился и сконфигурировался.
А ПКМ по CMakeLists.txt -> Build All Projects даже запустит и успешно завершит сборку. Казалось бы успех…
- xc.h не найден, а значит никакого автокомплита по регистрам и макросам компилятора и самого МК.
- Синтаксические ошибки не будут подсвечены, кроме ошибок поиска заголовочных файлов. И это проблема. VS Code не будет задействовать intellisense пока не будут разрешены ошибки заголовочников. (но даже если вы их разрешите — см. ниже)
- Прагмы, дефайны и спецсимволы компилятора аля __interrupt(low_priority) будут неизвестны и в лучшем случае светится ошибкой, в худшем рушить синтаксические конструкции и вызывать кучи ошибок в самых неожиданных местах.
- Системные заголовочники будут видимы, но при CTRL+ЛКМП по ним, вы попадете в папку какого-нибудь MSVC. В принципе с этим нет проблем, интерфейс стандартных библиотек везде одинаковый, а их использование IDE, не значит их использование компилятором, как и наоборот, вот этот момент надо всегда держать в уме. Но проблема в том, что там могут быть не только системные, но и другие заголовочные файлы, у меня это был gpio.h Что вызывало невидимость void SetGPIO(bool new_state)
для IDE и ошибку отсутствия определения. У вас похожая проблема может не возникнуть или возникнуть не сразу.
Для начала надо в файле воркспейса вписать строку, включающую отображение ошибок C++, что бы получилось так:
В отдельности это ничего не изменит, но потребуется для дальнейшего. (а может не потребуется, черт знает)
Далее, в корне проекта, в папке .vscode надо создать файл c_cpp_properties.json. Если папки не появилось, это норма, ее надо создать руками.
И копируем туда следующий жабсон код
После этого основные мои проблемы с VS Code закончились. Скорее всего у вас буду ваши, свои собственные, возможно описанное выше не решит их, но пусть оно будет хотя бы дополнительной информацией.
«Ментальные вызовы» VS Code
Помимо основных проблем, были еще мелкие:
1. Intellisense ТОРМОЗИЛЛЛллллллл, между изменением файла и окончанием парсинга проходили десятки секунд. Увы нормально не лечится, на гите вскода тикеты висят годами, после чего ехидный модер их закрывает с пометкой «наверно само вылечилось уже», но их позже переоткрывают энжой йор жабс. У меня была проблема, что заголовочники компилятора обильны и велики числом, особенно заголовки самих МК. В итоге, специально для IDE, я вынес их в папку с проектом, обрезал там все, что не требовалось моему процу и перенаправил пути инклудов IDE в жабсон туда.
2. Отображение ошибок лишь в открытых файлах. Не лечится. На гите вскода сказали, что и не будет в ближайшем будущем. энжой йор жабс
3. Отсутствие Refactor -> Rename по всему проекту. См. пункт 2. энжой йор жабс
Аутро
После микропроблемы пункта 3, была в ярости удалена, а ярость перенаправлена в русло борьбы с CLion, которое вроде завершилось успехом и будет описано позднее.
А вот и она.
Примерно с этого момента можно начать наслаждаться удобной IDE, платить подписку и делать уже что то полезное.
Мне согласился помочь доброжелатель описав настройку под QT Creator, так что думаю в скором времени будет дополнение.
Если есть желание и возможность уточнить технические, орфографические и пунктуационные моменты или описать дополнительные проблемы, решения, тонкости — буду очень рад.
Благодарности
Спасибо множеству людей из t.me/supapro и t.me/probuildsystems слушавшим мое нытье и глупые вопросы, не скупившимся на объяснение и помощь, на протяжении нескольких месяцев, пока я осиливал несколько этих строчек конфигурации IDE.
Читайте также: