company_banner

CLion 2019.1: ClangFormat, подсветка кода через Clangd, memory view, начальная поддержка микроконтроллеров

    Привет, Хабр!

    У команды CLion множество отличных новостей — питерская часть команды вместе с другими коллегами успешно перебралась в новый офис, к нам присоединились новые классные разработчики, а главное, мы буквально на днях выпустили первое большое обновление в этом году, CLion 2019.1!

    Работа в новой версии шла сразу по нескольким фронтам:

    • Усовершенствования поддержки языка C++: подсветка кода через Clangd, улучшения рефакторингов Extract и Rename, новая проверка на то, что функцию-член класса можно объявить статической.
    • Больше возможностей в настройках стиля написания кода: интеграция с ClangFormat, поддержка стилей именования переменных в C/C++, поддержка разных стилей для header guards.
    • Новые возможности и улучшения отладчика: просмотр состояния памяти — Memory View — для указателей, просмотр дизассемблированного кода в случае LLDB, ускорение работы пошаговой отладки.
    • CLion для микроконтроллеров, первые шаги.
    • Возможность создавать Build Targets и конфигурации для запуска/отладки в CLion, которые никак не связаны с проектной моделью.
    • Работа с другими языками программирования в строковых литералах в С/С++.
    • Новые визуальные темы и другие платформенные возможности.

    CLion 2019.1 release

    Подробнее об этих и других нововведениях читайте ниже. А чтобы попробовать новые возможности и улучшения, скачайте бесплатную 30-дневную версию CLion с нашего сайта.

    Поддержка языка C++


    Clangd


    Как вы уже знаете, в CLion два инструмента для поддержки языка C++ — один полностью свой, а второй основан на Clangd. Они работают совместно, дополняя друг друга и обмениваясь необходимой информацией. При этом, если производительность и критерий функциональной полноты позволяют, мы сейчас стараемся перенести умные средства по работе с кодом на C++ в CLion на инструмент на базе Clangd. Речь пока не идет про рефакторинги кода, но вот подсветка кода в 2019.1 сделана уже на базе Clangd. Это существенно улучшило “отзывчивость” редактора.

    Еще несколько релизов назад мы перевели CLion на инструмент на базе Clangd при показе ошибок в редакторе. Теперь текст ошибок показывается более детально. Это пригодится, например, при отладке ошибок, связанных с перегрузкой функций:

    Clang errors

    К этому добавилась возможность вычисления позиции возможного исправления (quick-fix) тоже через Clangd. Само же исправление предоставляется непосредственно собственным инструментом CLion.

    Еще одно интересное направление нашей работы — это написание новых проверок на инструменте парсинга кода на Clangd. Начиная с CLion 2019.1, новая проверка для кода на C++ подскажет, когда функцию-член класса можно объявить статической:

    Static member check

    Кстати, управление настройками этого альтернативного инструмента на Clangd можно найти в Settings/Preferences | Languages & Frameworks | C/C++ | Clangd.

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


    Производительность редактора является одной из наших самых приоритетных целей. Помимо множества небольших улучшений, в этом релизе стоит отметить существенное улучшение начального времени индексирования проекта. Оно случается не всегда, но в случаях, когда для своих проектов вы используете одни и те же библиотеки: тогда CLion может это автоматически заметить и переиспользовать символы для этих библиотек для нового открытого проекта, который их использует. Когда речь идет об STL или Boost, улучшения становятся очень заметными!

    В наших планах на этот год повышение аккуратности и точности наших рефакторингов для C++. Мы начали с двух самых базовых — Rename и Extract. Для Extract мы поправили множество случаев, когда результат рефакторинга оказывался некорректным из-за неправильно учтенных квалификаторов пространства имен (например, std::), специализаций шаблонов и переопределенных имен типов (type aliases).

    Применительно к Rename мы обратили внимание на случай, когда происходит переименование класса или структуры, совпадающей с именем файла, в котором они находятся. Раньше мы всегда переименовывали и файл тоже, а теперь CLion спрашивает вас о предпочтительном исходе во время рефакторинга. Можете переименовать, а можете оставить старое имя файла. В обратную сторону тоже работает — переименование файла не приводит к безусловному переименованию класса. (Где-то здесь должны быть крики из зала: “Наконец-то!”.)

    Rename class

    И, кстати, чуть ниже я расскажу о возможности задавать стили header guards. Так вот, если использованный в файле header guard следует заданному шаблону стиля и при этом в его имени есть имя переименованного файла, то CLion обновит и header guard!

    Стили кодирования


    В версии 2019.1 мы добавили возможность переключиться на ClangFormat для форматирования кода в CLion. Это включает в себя не только само действие форматирования (Ctrl+Alt+L на Windows/Linux, ⌥⌘L на macOS) или автоформатирование при печати кода, но и форматирование перед коммитом (pre-commit hook), при генерации кода средствами CLion, при рефакторингах и при применении исправлений (quick-fixes). В общем, в любом месте, где IDE форматирует код, будет вызываться ClangFormat.

    Переключиться на ClangFormat можно глобально — в настройках Settings/Preferences | Editor | Code Style. А можно только для конкретного проекта. Причем, если в проекте будет обнаружен конфигурационный файл .clang-format, CLion предложит переключиться на ClangFormat именно с использованием этого конфигурационного файла:

    ClangFormat

    Чуть больше деталей можно найти в нашем блоге (на английском).

    Именование переменных, типов и других символов в коде — сложный, порою даже философский вопрос. Но в мире программирования (для улучшения читаемости кода) давно придумали стили именования. Есть стиль LLVM, есть Qt, есть Google. Поэтому в настройках CLion Settings/Preferences | Editor | Code Style | C/C++ теперь появилась новая вкладка — Naming Convention, в которой можно выбрать один из предопределенных стилей или настроить свой, задав стиль именования для различных типов символов (макросов, глобальных функций, членов класса, параметров, локальных переменных и пр.). Выбранная конвенция будет использоваться во всех действиях IDE — кодогенерации, рефакторинга, автоматических исправлениях и т. д. Кроме того, если хочется еще более точно следить за выполнением правил именования, можно включить новую проверку Inconsistent Naming, которая покажет имена, не соответствующие правилам, и предложит вариант переименования:

    Naming convention

    В этой же вкладке можно найти настройки стиля header guards, которые я упоминала выше:

    Header Guards

    Кстати, если вы предпочитаете использовать #pragma, то просто поправьте шаблон новых заголовочных файлов в Settings/Preferences | Editor | File and Code Templates.

    Отладчик


    Просмотр памяти Memory View


    У нас наконец дошли руки до просмотра памяти в отладчике. В текущей версии можно посмотреть память по указателю: достаточно встать на любой указать в панели Variables во время отладки и запросить Memory View (Ctrl+Enter на Windows/Linux, ⌘Enter на macOS). А если вкладка memory view открыта при пошаговой отладке, то в ней можно видеть подсвеченные изменения в памяти:

    Memory View

    На следующий релиз уже запланированы изменения в UI/UX, но сначала хотелось бы собрать отзывы от пользователей. Так что пишите!

    Дизассемблирование в случае LLDB


    Ассемблерный код теперь разбит по функциям и, главное, показывается не только в случае GDB, но и для LLDB!

    Disassembler LLDB

    Стоит, правда, отметить, что ассемблерный код показывается до сих пор только в тех случаях, когда нет исходных кодов функции. Так называемый режим disassemble on demand пока не поддержан.

    Производительность пошаговой отладки


    Иногда пошаговая отладка затягивается из-за длительного вычисления переменных на каждом шаге. Но ведь порою эти вычисления никому не нужны — хочется как можно быстрее пройти какую-то область кода по шагам, изредка просматривая значения пары переменных! Теперь в CLion появилась возможность отключить пересчет переменных при пошаговой отладке — Mute Variables в контекстном меню отладчика делает ровно это. А когда понадобится вычислить и отобразить значения, на переменной можно нажать Load:

    Mute variables

    CLion для микроконтроллеров


    Илья Моторный (elmot) уже писал здесь на Хабре про свой плагин для интеграции CLion с STM32CubeMX и поддержкой отладчика OpenOCD. В конце прошлого года Илья присоединился к нашей команде и уже успел существенно обновить плагин и перенести его внутрь CLion.

    CubeMX integration

    Довольно большой и детальный блог пост по обновленному плагину можно найти в нашем блоге. Здесь же я опишу самое главное, что теперь можно сделать:

    • В диалоге New Project можно создать проект STM32CubeMX (.ioc).
    • Прямо из CLion запустить для проекта STM32CubeMX, чтобы обновить настройки микроконтроллера и сгенерировать код для проекта.
    • CLion при этом сам сгенерирует корректный CMake-файл для работы с этим проектом.
    • CLion предложит выбор конфигурационного файла для железа (board config).
    • Для отладки с помощью OpenOCD нужно создать конфигурацию специального типа “OpenOCD Download and Run”. Для проекта STM32CubeMX CLion создаст такую сам. Указав все настройки, можно отлаживаться на микроконтроллере прямо из CLion!

    У Ильи много грандиозных планов, поэтому нам очень важны ваши отзывы. Так что, если вам интересна разработка под встроенные системы в CLion, ждем вас в комментариях!

    Проектно-независимые таргеты и конфигурации


    Некоторое время назад список поддерживаемых проектных моделей в CLion был расширен Gradle C++ и compilation database. С последним были проблемы, связанные с тем, что формат не включает информацию о сборке всего проекта, поэтому ни сборка, ни запуск, ни отладка проекта в случае compilation database не были возможны. Да и просто в случае известной CLion проектной модели, иногда хочется иметь таргет, который просто собирается какой-то командой в терминале.

    Теперь для таких случаев есть Custom Targets (Settings/Preferences | Build, Execution, Deployment | Custom Build Targets) и Custom Run/Debug Configurations (Run | Edit Configurations…). В случае таргета надо задать параметры внешних инструментов (external tools), которые будут использоваться при сборке и очистке проекта:

    Custom targets

    А в случае проектно-независимой конфигурации для запуска и отладки надо указать таргет, исполняемый файл и желаемые аргументы для запуска:

    Custom configuration

    Injected Language


    Встречаются ли в вашем коде строковые литералы, внутри которых запрос SQL, HTML код или регулярное выражение? Если да, то наверняка вам бы хотелось хотя бы подсветить код внутри литерала в соответствии с его происхождением. Теперь это возможно! Временно включить в строковом литерале другой язык можно простым нажатием Alt+Enter и выбором опции “Inject language or reference”. Теперь выбираем нужный нам язык и в еще недавно обычном строковом литерале появляется подсветка выбранного языка, а также все специальные действия. Самый яркий пример — регулярные выражения и возможность проверки строки на соответствие им прямо в IDE:

    Injected language

    И многое другое


    Продукты в компании JetBrains как правило создаются не одной небольшой командой, а командой всей соответствующей платформы. Поэтому в CLion попадают возможности из IntelliJ IDEA, WebStorm, AppCode, DataGrip, PyCharm и пр. В этом релизе из таких улучшений стоит отметить:

    • Просмотр всех мест в коде проекта, где разработчик производил какие-то изменения или просто читал код, — Recent Locations Popup (Shift+Ctrl+E на Win/Lin, ⇧⌘E на macOS).
    • Создание новых тем для интерфейса IDE, в дополнение к стандартным светлой, темной (Darcula) и контрастной (High-Contrast). Примеры таких тем-плагинов и пошаговый туториал можно найти в нашей документации.
    • Кстати, о плагинах. Если вы пишете на Rust, то наверняка знаете, что есть плагин IntelliJ Rust. В CLion его версия включает поддержку Cargo и отладчик. А с новым релизом в плагине появились инструменты профилирования кода на Линуксе и macOS, возможность автодополнения еще не импортированных символов, а также другие улучшения.

    На этом пока все. Спасибо, если дочитали до конца!

    Демо


    Ну, и традиционный ролик о новых возможностях CLion 2019.1 (на английском):


    Вопросы, пожелания, баг-репорты и просто мысли высказывайте в комментариях! Мы будем рады ответить.

    Ваша команда JetBrains CLion
    The Drive to Develop
    JetBrains
    186,00
    Делаем эффективные инструменты для разработчиков
    Поделиться публикацией

    Комментарии 37

      0
      А когда понадобится вычислить и отобразить значения, на переменной можно нажать Load
      А есть ли возможность сделать mute для всех переменных, кроме одной? Зачастую все же хочется следить за состоянием одной-двух переменных на каждом шаге.
        0
        Сейчас мьютятся все, более сложную логику можно сделать теоретически, заведите задачку в трекере. В принципе, на каждом шаге можно пока Load нажимать на этой переменной.
          0
          Кстати, я не совсем права, если добавить нужные переменные в Watches — они мьютиться не будут. Так вроде как раз выходит то, что нужно.
            0
            Да, то что нужно, спасибо.
          +1
          Занимаюсь разработкой для встраиваемых систем. Преимущественно ST, TI, NXP, но разрабатываю и отлаживаю всё в eclipse, есть интересный проект (скорее всего команда CLion в курсе) gnu-mcu-eclipse мне кажется у них можно позаимствовать интересные идеи.
          Отладчиком пользуюсь часто. И особенно мне нравится возможность просмотра регистров периферии прямо во время отладки.
          Есть ли поддержка SVD в CLion? они позволяют просматривать регистры периферии конкретного микроконтроллера прямо во время отладки. SVD — это XML файл с описанием регистров периферии(в JSON было бы удобнее, моё мнение). Было бы здорово иметь возможность дополнять эти файлы более подробным описанием регистров прямо в IDE и скидывать свои дополнения или справления в общий котёл.
          0
          Скажите пожалуйста, когда примерно ожидать отладчик под msvc? Прочитав план на релиз 2019.1 заглядывал в каждый eap билд)
            0
            Он в процессе. Так как он пишется с нуля, на базе LLDB, то это не быстрый процесс. Сейчас есть версия, где работает степпинг + мы научились читать natvis файлы. Но не поддержан еще пока evaluate templates, без этого будет тяжело поддержать STL. Но мы надеемся в EAP на 2019.2 хотя бы какаю-то экспериментальную версию показать широкой публике.
            +1
            А когда ожидать debugging с MSVC? Очень необходимая вещь, без неё почти невозможно.
              0
              Ну вот выше как раз ответила. Читайте
              0

              скажите, а когда будет, и будет ли, возможность поменять генератор для cmake?

                0
                Появится, когда мы поддержим CMake-server (CPP-8238). В 2019.2 вряд ли успеем, к сожалению.
                +1
                Ура! Микроконтроллеры! Еще чуть чуть и можно будет переезжать с visualGDB. Было бы круто реализовать удобный вывод отладочной информации через SWO trace, например, строить графики по данным измерения АЦП.

                Правда одно не понятно — зачем вообще интегрировать этот куб? Во-первых, это поделка для школьников и рукожопов не профессиональных разработчиков, то есть для людей, который точно не купят у вас лицензию. Во-вторых, микроконтроллеры (даже на Cortex-ах) не заканчиваются на STM32, поэтому логичнее потратить силы на другой инструментарий.
                  0
                  Мы довольно долго исследовали рынок и STM32 выглядит как наиболее подходящая первая цель. Но будем расширять поддержку в дальнейшем и для других семейств микроконтроллеров.
                    0
                    Не знаю, какой Вы исследовали рынок, но в среде профессиональных разработчиков встраиваемых систем «Куб» не в почете. STM32 действительно имеют широкую аудиторию, но надо рассматривать более обширно рынок, например «силовики» используют семейство TMS от TI, разработчики IoT активно используют NRF от Nordic. Многие микроконтроллеры идут с SDK или библиотеками различных стеков (BLE, 6LoWPAN и т.д.) следовательно надо реализовывать поддержку этих дополнений. На многих фирмах используются микроконтроллеры различных семейств и ядер, и на каждый тип микроконтроллеров приходиться ставить свой инструментарий. Для затравки новость интересная, но на сегодня мало кого из аудитории профессиональных разработчиков встраиваемых систем заинтересует пока неполноценный продукт. Вам стоит пообщаться с разработчиками встраиваемых систем напрямую, чтобы выяснить потребности.
                      0
                      Я не говорила, что Cube супер популярен. Я лишь сказала, что STM32 наиболее интересная пока группа. Cube был поддержан у Ильи в плагине и у него есть определенная аудитория, поэтому мы перенесли в продукт. Конечно, это не самый важный инструмент для STM-семейства. OpenOCD поддержка в этом плане более масштабная, по количеству кейсов использования.

                      С разработчиками встроенных систем мы общаемся. Во-первых, в рамках исследования мы делали большой опрос.

                      Во-вторых, у нас в команде несколько разработчиков, в прошлом занимавшихся встроенными системами. У всех, конечно, свой опыт, но какую-то интересную выборку дает. Я вот сама проработала в embedded networking, делала всякие IP routers/gateways, IPTV и прочие интеерсные железки. У Elmot опыт скорее любительский, зато диапозон попробованных MCU большой.
                        0
                        опыт скорее любительский, зато диапазон попробованных MCU большой

                        Поймите, любительский большой диапазон попробованных сильно отличается от большого диапазона используемых профессиональным разработчиком. И потребности соответственно отличаются. Например, NordicEnergy в своей работе использует различный спектр микроконтроллеров и его Ваш продукт пока не сильно заинтересовал.
                          0
                          Мы и не расчитывали, что после добавления OpenOCD поддержки и куба этим заинтересуются большие профессиональные embedded разработчики. Все еще впереди!
                            0
                            Самое главное сделать нормальную поддержку кросс компиляторов, чтобы можно было хотя бы проект сделать с тулчейном под популярные кросс компиляторы типа IAR и GCC… Потому что Cube это хорошо, но им нельзя пользоваться при разработке ПО для промышленных надежных устройств.
                            А то сейчас вроде и разрабатывать можно и отлаживаться, но при этом половина функций не работает. Основная трабла, компиляторы не проходят проверку при создании Cmake проекта или при его обновлении, обещали вроде в 2019.2 поправить, ждем…
                              0
                              Собственно GCC поддержан. Проверка компиляторов в cmake просто отключается.

                              Не понимаю ваших проблем с кубом — он просто генерирует код для настройки периферии и клокинга, почему им нельзя пользоваться?

                              А что(и, главное, кто) Вам обещали в 2019.2, если не секрет?
                                0

                                Что то у меня Gcc подключать не хочет, падает при создании Cmake проекта…
                                Я беру его отсюда https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
                                В настройках ставлю MinGw и подсовываю компиляторы со ссылки и получаю ошибку, что компилятор не может справиться с простым тестом при создании. Cmake проекта.
                                Если подсовывать IAR компилятор, то почти проходит, за исключением компиляции с каким то ключом, который он не знает.
                                В итоге проект компилитсясвсе таки, но пути к заголовочникам не видит. Вот, например:
                                [YouTrack, Commented] Issue CPP-12576: include_directories ignored by 'inspection' if compiler check fail
                                И вот,
                                [YouTrack, Commented] Issue CPP-12788: Toolchain file break highlighting
                                И все это под этим:
                                [YouTrack, Voted] Issue CPP-871: Support for cross-compilation/debug and embedded development


                                Мне обещали исправление ошибки при создании Cmake проекта и связанных с ней типа проблемы с нахождением путей к include заголовочникам, сейчас приходится прописывать полный путь в исходниках…
                                А путь к std заголовочникам вообще не знаю как прописать.


                                Куб генерит код, но этим кодом нельзя пользоваться в реальной жизни, так как у этого кода даже просто много ворнингов от компилятора, не говоря уже про проверку статическим анализатором кода, в генереном коде баги, например в USB (но это то что сам видел и прочувствовал), так то даже в CMSIS есть баги с выравниванием структур… А в кубе и подавно.
                                Ну и кода там генериться мама не горюй, чтобы светодиодом поморгать… В общем для дома и учеба самое то, а для промышленных применений такой генерый код не пройдет ни одной сертификации..

                                  0
                                  GCC: Отключите проверку компиляторов
                                  SET(CMAKE_C_COMPILER_WORKS 1)
                                  SET(CMAKE_CXX_COMPILER_WORKS 1)
                                  

                                  IAR, конечно, в планах, но не сейчас

                                  Т.е. баги не в самом кубе, а в стандартных библиотеках. Тут я соглашусь, особенно про их ужасный USB.
                                  Тем не менее, даже с необходимостью править косяки в библиотечном коде в целях сертификации, куб очень полезен в начале проекта на сложных чипах(F4, F7, L4, H7, WB), иначе там чтения доки на несколько недель.

                                  А путь к std заголовочникам вообще не знаю как прописать.

                                  По идее само долно найтись, если тулчейн в path.
                                    0
                                    Ок, спасибо попробую. По поводу IAR, он работает нормально, все компилится, отлаживается, вопрос только в том, что не работает include_directories и-за этого пути не работают… если сделать работу include_directories, то этого вполне хватит…
                                    Насчет Куба, я согласен, что полезен он для быстрого начала, для проверки там идей и так далее, но по хорошему даже метод обращения к регистрам нужно менять в CMSIS. И да доки придется читать. Но без этого никуда, как говориться, лучше день потерять, потом за пять минут долететь :)
                                    Для примера, что в голову пришло…
                                    class RegisterReadOnly 
                                    { 
                                    };
                                    class RegisterWriteOnly 
                                    { 
                                    };
                                    class RegisterReadWrite : public RegisterReadOnly, public RegisterWriteOnly 
                                    { 
                                    };
                                    
                                    template <std::size_t size, typename RegisterType, std::uint32_t address,
                                    typename std::enable_if_t<std::is_base_of<writeOnly, RegisterType>::value>>
                                    class Register
                                    {
                                    public:
                                      using registerType = typename RegisterTraits<size>::internalType;  
                                      constexpr Register(): reg{*reinterpret_cast<std::uint32_t*>(address)}
                                      {
                                      } ;  
                                      Register& operator=(const registerType& right) 
                                      {
                                        reg = right ;
                                        return *this ;
                                      }  
                                      Register& operator |=(const registerType& right)
                                      {
                                        reg |= right ;
                                        return *this ;      
                                      }  
                                    private:
                                      volatile registerType & reg;
                                    };
                                    
                                    int main()
                                    {
                                       Register<32U, RegsiterReadWrite, GPIOA_MODER_BASE_ADDR> GpioaModer;
                                       GpioaModer |= (1 <<3) ;
                                       Register<32U, RegsiterReadOnly, ADC1_SR_BASE_ADDR> Adc1SR;
                                       Adc1SR |= 1 ; // ошибка компиляции, так как регистр ReadOnly
                                    }
                                    

                                      0
                                      По-моему, это перебор.
                                      И там же тысячи регистров со своими особенностями (битовые поля, различные назначения битов, зарезервированные значения и прочее разрушающее чтение), это будут гиганские объемы кода. Лучше уж статический анализатор запилить, который берет SVD файл и проверяет все эти заморочки, причем неспецифичным к чипу и вендору способом.

                                      Кроме того, библиотеки на С, а не на плюсах.
                                      И это вряд ли изменится в обозримом будущем.
                                        0

                                        ) Ну да, но за плюсами будущее, библиотеки потихоньку переписываются, а по моей специфике мы пишем все библиотеки сами, так как код сертифицируется на SIL3 и Си там не приветствуется, по сколько совсем не совсем он строго типизированный.
                                        Кстати регистров много, но отличаются они только адресами, типом доступа и размерностью…
                                        Кто то же CMSIS заголовояники для каждого процессора написал ( с ошибками кстати), тут просто дело времени, но ошибок меньше, например можно проверить, что структура выровнена по размеру регистррв и не имеет дырок и все это во время компиляции.

                                          0
                                          ну блин… а что делать со всякими битбэндами, скажем? не использовать? Так это иногда дает нехилый прирост по скорости.
                                          В целом я все равно за статический анализатор в данном случае.
                                  0

                                  Забыл сказать, у меня Windows, возможно под Linux таких проблем нет...

                          0
                          Многие микроконтроллеры идут с SDK или библиотеками различных стеков (BLE, 6LoWPAN и т.д.) следовательно надо реализовывать поддержку этих дополнений.

                          Да, это абсолютно верно. Какую поддержку для этих SDK и библиотек было бы желательно иметь, кроме того, что уже идет из коробки? В CLion уже есть довольно мощный редактор кода, отладчик, memory view. Запланирована поддержка Peripheral Registers View
                        0
                        А мы и не ограничиваемся stm32, куб — это опциональная вещь для быстрого старта. Вы уже сейчас можете использовать CLion для любых микроконтроллеров, которые поддержаны gcc, gdb и openocd. Естественно, поддержку других МК мы тоже будем расширять.

                        потратить силы на другой инструментарий

                        Если есть пожелания по конкретным утилитам, то заведите тикет, мы посмотрим, что можно сделать
                          0
                          У Вас в профиле написано «На данный момент не занимаюсь разработкой ПО!». Зачем вообще это все Вам?
                            0
                            Кажется, стоит явно упоминать того, кому задаете вопрос) А то не понятно.
                              0
                              Что именно? Надпись? Мне в неделю прилетает десяток-два предложений с проектами, вот чтобы люди не тратили ни свое, ни мое время и было указано, что задачи по ПО посредственные не ко мне, только железо или fpga/наука.
                              А так для своих основных проектов таки код пишу, поэтому Нам это надо, в смысле новые и хорошие инструменты для разработки :))
                            0
                            Использую CLion уже больше года — все нравится.
                            Но пару дней назад переехал на ноутбуке с macos high sierra на ubuntu 19.04.
                            И начались сильные тормоза из-за CLion. При редактировании проекта использование cpu подскакивает на максимум. При включенном power saving режиме такого нет.
                            Под макосью таких проблем не наблюдалось. Проекты ровно те же самые редактировались.
                            Грустно :(
                              0
                              Это все очень странно. Снимите и зашлите CPU snapshot в наш саппорт. Мы посмотрим
                              0
                              Поддержка «Naming Convention» радует, но условный «camelCase» вы почему-то разделили на «PascalCase» и «camelCase», а «snake_case» в варианте с первой заглавной буквой нет.
                                0
                                Да, мы уже осознали, что забыли про Upper_Snake_Case, он появится в ближайшем апдейте 2019.1.1

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое