company_banner

Релиз CLion 2016.2: удаленная отладка, поддержка формата Doxygen, новые возможности кодогенерации и многое другое

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

    Чуть больше года прошло с момента первого релиза нашей кросс-платформенной IDE для разработки на C и C++. За это время у нас появились десятки тысяч пользователей, среди клиентов встречаются такие организации, как NASA и AirBnB, а самый популярный запрос в трекере набрал более 500 голосов. И кстати, мы не зря просим вас голосовать за те запросы, которые вам наиболее интересны или актуальны. Наша очередь задач на разработку зависит от вашего мнения и ваших голосов в первую очередь. Именно поэтому релиз 2016.2 включает в себя так много долгожданных возможностей!



    А теперь обо всем по порядку.


    Отладчик: производительность, корректность и новые поддерживаемые версии


    Наши пользователи часто жаловались на различные пробелемы с отладчиком в CLion — то command timeout случается во время отладки программы, то значения переменных в окне Variables не обновляются, то дебагер некорректно завершает свою работу. К этому всему добавлялась проблема производительности, когда использование отладчика на программах с объемными структурами данных становилось затруднительным.

    Собрав все логи и репорты от наших пользователей (кстати, спасибо вам за них огромное!), мы наконец смогли существенно переработать драйвера для GDB/LLDB отладчиков, используемых в CLion. Множество проблем было решено (в частности, та самая с command timeout), а самое главное, производительность отладчика значительно улучшилась (кое-где в 600 раз!). Так, например, на наших тестах скорость пошаговой отладки программ с просмотром массивов улучшилась в 600 раз для GDB и в 1-2 раза для LLDB; с развернутым содержимым классов — в 160 раз; а многие тесты (например, отладка с просмотром строк или коллекций STL), которые раньше завешались по таймауту, стали заканчиваться за разумное время.


    Заодно мы обновили поддерживаемые версии: GDB до 7.11, LLDB до 3.8, а вместе с ними MinGW-w64 до 5.* и Cygwin до 2.*.

    LLDB в CLion теперь доступен не только нашим пользователям на macOS, но и на Linux.

    Отладчик: удаленная отладка c GDB


    Уверена, многие из вас ждали этой возможности. Сразу оговоримся, что пока что это самая первая реализация того, как мы видим удаленную отладку в IDE. Так что, если вы знаете о полезных случаях использования, которые мы не учли, обязательно расскажите нам о них.

    Итак, текущая реализация подразумевает отладку с GDB и GDB-сервером. Последний запускается на таргет-хосте, а вам остается лишь правильно сконфигурировать настройки Remote GDB Configuration в CLion для удаленного подключения. Когда соединение будет успешно установлено, вы сможете отлаживать удаленно запущенную программу, выставляя точки останова в IDE, просматривая значения переменных или даже изменять их на лету, вычислять значения выражений.


    Интерфейс для конфигурации довольно прост и включает в себя те параметры, которые вы бы использовали, вручную настраивая GDB/gdbserver:


    На данный момент удаленная отладка не доступна на Windows. Также на macOS требуется использовать специальную версию GDB, скомпилированную с флагом --target=x86_64-linux-gnu (подробнее смотрите здесь).

    Документация: поддержка Doxygen


    Как известно, хорошая степень документированности кода — залог того, что код будет легче поддерживать в будущем. В разработке на C++ (да и не только) одним из самых популярных форматов документации кода является Doxygen. Поэтому мы решили добавить его поддержку в эту версию. В чем же она заключается?

    Во-первых, для кода, документированного с использованием комментариев Doxygen, окно Quick Documentation (Ctrl+Q на Linux/Windows, F1 на macOS) в дополнение к информации о типе элемента показывает превью документации. Из удобных возможностей стоит отметить, что если параметры функции в коде документированы раздельно, то Quick Documentation для функции сможет объединить все комментарии и показать общее описание сигнатуры:


    К тому же, если вызвать окно Quick Documentation, когда курсор находится на имени параметра в комментарии Doxygen, будет показана информация о типе данного параметра:


    Во-вторых, при рефакторинге функции, если, к примеру, вы решите переименовать ее параметр, комментарии Doxygen будет автоматически обновлен:


    Ну и наконец, если вы решите добавить новые комментарии Doxygen в код проекта, воспользуйтесь автодополнением для команд Doxygen и параметров функций. Или просто сгенерируйте шаблон документации для его дальнейшего заполнения (работает при использовании “/**”, “/*!”, “///” и “//!”, при условии, что у документируемой функции имеются параметры, она возвращает значение или кидает исключение):


    Настройки внешнего вида сгенерированных шаблонов находятся в Editor | Code Style | C/C++.

    Complete Statement


    Хотя возможность это не новая, в версии 2016.2 она была значительно переработана и улучшена. Суть в том, что CLion завершает за вас конструкции кода, расставляя необходимые скобки, точки с запятой, кавычки, а также передвигая курсор в позицию, в которой вы можете начать печатать следующую конструкцию. Это работает для пространств имен, классов, структур, управляющих конструкций и пр.:


    Подробнее читайте в нашем блоге.

    Генерация кода


    CLion позволяет сэкономить время на печати кода, предоставляя различные варианты кодогенерации: от генерации конструкторов/деструкторов класса до разнообразных шаблонов (live templates). В версии 2016.2 мы добавили возможность сгенерировать операторы сравнения, равенства и печати (stream output). Гибкий интерфейс позволяет не только выбрать поля класса, которые необходимо использовать, но и указать, создавать ли операторы как члены класса, использовать ли std::tie в реализации и т. д. При этом CLion анализирует, есть ли уже в классе какие-либо операторы из тех, которые пользователь хочет сгенерировать, и может либо пересоздать их, либо добавить недостающие:


    В прошлом релизе мы представили возможность генерировать определения (generate definitions), при этом реализованное поведение по выбору места, куда CLion помещает созданные определения, вызвало большие споры и обсуждения. Мы проанализировали все комментарии наших пользователей и в релизе 2016.2 поменяли поведение, сделав его адаптивным. Фактически, CLion сам распознает и поддерживает три основные модели:
    • декларации расположены в заголовочных файлах, реализации — в .cpp-файлах;
    • классы/структуры полностью расположены в заголовочных файлах;
    • классы/структуры полностью расположены в .cpp-файлах.


    Конечно, вы в любой момент при генерации определений можете изменить используемую модель. CLion запомнит новое поведение и предложит вам его при следующем вызове функции генерации:


    Умная поддержка CMake


    Мы продолжаем работать над облегчением написания CMake-кода в проектах. В этом релизе мы поддержали два рефакторинга для CMake:
    • Rename (Shift+F6 на Linux/Windows, ⇧F6 на macOS) — позволяет переименовывать пользовательские символы, функции и макросы. CLion сам обновит все случаи использования.
    • Safe delete — с одной из самых первых версий, при добавлении нового файла в проект, CLion предлагал добавлять новые файлы в таргеты CMake. Теперь поддерживается и удаление файлов из проекта, а именно, все упоминания файла будут удалены из команд CMake. А если CMake-файлы могут оказаться некорректными после удаления (если удаляемый файл был последним аргументом команды), будет показано предупреждение:



    Нас часто просили сделать способ для определения того, что вызов CMake происходит именно из CLion. В этом случае многие пользователи хотели бы иметь возможность выставить дополнительные переменные или изменить какие-то используемые пути. Теперь такой способ есть — переменная окружения CLION_IDE. А чтобы ее было проще найти, реализовано автодополнение для переменных окружения:


    Форматирование кода


    CLion предлагает множество настроек форматирования и заранее предопределенных стилей. В новом релизе помимо нескольких новых опций были также добавлены новые стили — LLVM и LLDB.

    Общие улучшения IntelliJ-платформы


    Релиз CLion 2016.2 также содержит и общие изменения в платформе IntelliJ:
    • Пользователям Windows теперь (как до этого пользователям Linux и macOS) доступна сборка с кастомизированной JDK, содержащей исправления и улучшения от команды JetBrains.
    • Поддержка шрифтов с лигатурами (включается в настройках Editor | Colors & Fonts | Font, выбрать шрифт с поддержкой лигатур и включить опцию “Enable font ligatures”):

    • Для тех, кто любит фоновые заставки, добавлена поддержка фона в редакторе. Чтобы ее включить, вызовите Find Action (Shift+Ctrl+A на Linux/Windows, ⇧⌘A на macOS), введите Set Background Image, укажите файл с картинкой и настройте прозрачность и другие параметры фона.
    • Поддержка Version Control Systems получила множество улучшений:
      • Файлы, которые не включены в текущий репозиторий, теперь указываются в окне коммита специальных образом, чтобы вы не забыли их.
      • Лог Git и Mercurial подгружается в фоновом режиме при любом изменении (и при загрузке проекта, и при изменениях в локальном репозитории), чтобы всегда быть полностью готовым, когда вы на него переключитесь.
      • Для Git мы исправили неприятную проблему, с которой наверняка сталкиваются пользователи Windows и macOS: переименование файлов, где меняется только регистр символов.
      • Для улучшения работы с патчами добавлена возможность копирования через буфер обмена (или простого перетаскивания файла мышкой) — IDE автоматически предложит применить патч.
      • Кроме того, если файлы, которые затрагивает патч, были переименованы или перенесены, IDE попытается их найти или попросит вас указать новый путь.
      • А непосредственно перед применением патча его содержимое можно сравнить с локальной копией и, при необходимости, внести какие-то изменения.



    Swift


    Начиная с прошлого релиза в CLion появился плагин для написания кода на языке Swift. Он особенно интересен тем, кто сейчас осваивает Swift на Linux. Команда AppCode продолжает работать над поддержкой языка, не забывая (за что ей огромное спасибо!) портировать изменения в плагин к CLion. В этой версии добавлена поддержка Swift 2.2, а также долгожданный рефакторинг — Introduce Variable, и поддержаны шаблоны для параметров (parameters placeholders). Узнайте больше на странице What's New новой версии AppCode 2016.2.

    Демо


    И традиционно, небольшое видео (на англ.), демонстрирующее новые возможности CLion 2016.2:


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

    Ваша команда JetBrains CLion
    The Drive to Develop

    JetBrains

    376,00

    Делаем эффективные инструменты для разработчиков

    Поделиться публикацией
    Комментарии 79
      +1
      Valgrind по-прежнему только в планах?
        0
        Да, руки пока до него не дошли. Но мы про него помним.
          0
          Ы-ы-ы, обновился — слетел честный тичерский ключ…
            0
            Попробуйте ввести заново. Заработает?
              0
              Подхватился, OK. Погоняю :)
                +1
                Отлично. Извините за неудобства.
              0

              С персональными такое тоже бывало, но повторный ввод обычно решал проблему.

                0
                Сейчас это as designed, но с переходом на подписки перестало быть логичным: поменяем.
          0
          Вы планируете сделать поддержку тонкого клиента? Когда на локальной машине работает только легкий интерфейс, а все остальное на удаленной? И улучшить vim-плагин?
            +1
            > Вы планируете сделать поддержку тонкого клиента? Когда на локальной машине работает только легкий интерфейс, а все остальное на удаленной?

            Текущие планы такие: сейчас вот только разобрались с удаленной отладкой; в дальнейшем будем думать про удаленное открытие проекта и запуск вот тут. Каких-то конкретных дат пообещать не могу.

            Глобальная идея тонкого клиента интересна и обсуждается. Но опять же ничего конкретного не можем пока предложить.

            > И улучшить vim-плагин?

            А что именно хотелось бы улучшить? У нас есть трекер плагина — закидывайте туда свои идеи, если они еще не там.
            0
            Как насчет поддержки managed-C++?
              +1

              Visual Studio + Resharper++

                0
                и в подметку не годится по сравнению с C# + R# :(
                0
                Нет в планах, так как, как верно было замечено, для этих целей есть ReSharper C++. А что именно в нем не устраивает?
                  0
                  Меня тут поправили, что ReSharper C++, к сожалению, тоже не умеет. Пока по-крайней мере
                0
                Ну и наконец, если вы решите добавить новые комментарии Doxygen в код проекта, воспользуйтесь автодополнением для команд Doxygen и параметров функций. Или просто сгенерируйте шаблон документации для его дальнейшего заполнения (работает при использовании “/*”, “/!”, “///” и “//!”, при условии, что у документируемой функции имеются параметры, она возвращает значение или кидает исключение):

                Это очень радует.


                с одной из самых первых версий, при добавлении нового файла в проект, CLion предлагал добавлять новые файлы в таргеты CMake.

                А можно где-то про это прочитать подробнее? Я недавно начал работать с CLion, но CMake редактирую вручную, не нашел каких-то автоматических функций.

                  0
                  Например, здесь.
                  Суть в том, что, когда вы создаете файл через create new class/source file/header file, в диалоге создания файла CLion предлагает обновить таргеты и даже показывает те, которые по его мнению подойдут.
                  +3
                  Очень хочется поддержку других билд-систем. Или хотя бы ручную настройку проекта как в Eclipse. Переносить всё на CMake не вариант.
                    0
                    Понимаю. Но пока у нас ресурсы до этого не доходят. Есть еще куча всего по CMake, что надо сначала доделать.
                    +2
                    А несчастному разработчику, который героически исправляет 261 баг парсинга C++, вы молоко за вредность даёте?
                      +3
                      Он не один там, к счастью. Сейчас несколько человек работают над языковыми фичами.
                      +2
                      Пользуясь случаем, спрошу: есть возможность полностью выключить диагностику на участке кода? Прагмами, например? Использую пару библиотек, полных шаблонной магии и C++14, код местами весь красный. Вообще, интересно было бы узнать планы по улучшению поддержки языка.
                        +1
                        C++14 пока не поддерживается, но на какие-то изменения в этом направлении надеемся уже в следующем релизе. Более точно планы озвучим чуть позже в блоге.
                        Инспекшены можно отключать через правую клавишу в меню квик-фиксов, но это не работает если проблема в парсере (красный код).
                          +1
                          И тут непонятно что происходит: http://xxo.su/resizer/i/e/4/6102b63f.png
                          Эклипс и прочие Code::Block с кодлайтами этот фрагмент парсят без проблем.
                            0
                            А вы не могли бы пример проекта для воспроизведения закинуть к нам в трекер?
                              0
                              Это не «проект» в общем понимании. Этот файл — промежуточный результат при компиляции kernel module, и в состав проекта не входит. Но иногда хочется посмотреть что там наавтогенерилось, вот и открываю его в том же редакторе. А там всё такое красное :)

                              Ну, то есть, для воспроизведения проект не нужен, достаточно одного файла. Или речь о том, что на работу парсера влияет факт включения или невключения файла в проект?
                                0
                                Похоже там какие-то проблемы с __used (он даже не подкрашен судя по скриншоту). А можете сделать go to dedclaration на __used? Куда будет осуществлен переход?
                                  0
                                  Никуда. А определение на самом деле в файле <linux/compiler.h>, который там включается явно, сверху третьей строчкой (да и неявно из <linux/module.h> в первой же строке). И определение это пустое :) То есть тупо "#define __used /* unimplemented */".
                                    0
                                    ок, мы завели багу — попробуем воспроизвести на своей стороне и будем изучать/править. Спасибо!
                                      0
                                      Файл закинуть? BTW, проблемы начинаются ещё раньше: http://xxo.su/resizer/i/8/7/a5868f0.png. При попытке прыгнуть на определение MODULE_INFO выдаёт «Cannot find declaration to go» (находится оно в <linux/module.h>).
                                        0
                                        Если можете, закиньте, пожалуйста.
                        +3
                        А семантическую раскраску сделайте, пожалуйста!

                        И чтобы можно было собирать несколько cmake-таргетов сразу. И чтобы выбирать их можно было в дереве файлов в директории с соответствующим CMakeLists.txt, где они задаются.
                          0
                          Семантическая раскраска в разработке. Не могу пока пообещать, когда что-то готовое сможем показать, но надеюсь — скоро.

                          Про CMake-таргеты не очень понятно. Конфигурации в CLion соответствуют таргетам в CMake, то есть как зададите в CMake, так и будет. Build All — дефолтовый CMake таргет — собирает все по умолчанию. Дальше — как настроите в CMake.
                            +1
                            Про таргеты лучше пояснить на примере.

                            Вот есть у меня проект, в котором есть куча своих подпроектов со своими CMakeLists.txt. В KDevelop, которым я сейчас пользуюсь, я могу нажать правой кнопкой мыши на любую директорию с CMakeLists.txt и добавить её в список сборки (это эквивалентно переходу в относительный путь от корня проекта до папки, но в билддире, если я правильно понимаю).
                            Скрин
                            image


                            Там внизу как раз список выбранных вещей имеется.

                            Аналогично я могу добавить отдельные цели для каждого из отдельных таргетов, равно как и одноразово собрать их (что удобно, если есть таргет для, не знаю, обновления переводов):
                            Скрин
                            image
                              0
                              CLion для любого таргета в CMake по умолчанию сгенерирует вам конфигурацию. Ее имя будет совпадать с именем таргета. Дальше вы также можете выбирать конфигурацию и запускать ее. Видимо главная сложность, что эти конфигурации не привязаны к дереву файлов в project view. Так?
                                0
                                Основная сложность в том, что я могу выбрать только одну конфигурацию. В том же kdevelop я могу выбрать произвольное число таргетов (он конфигурациями не оперирует) и собирать их в произвольном порядке (с учётом описанных в cmake зависимостей, конечно). В CLion я не могу выбрать больше одной конфигурации.

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

                                Но это так, юзабилити. А вот невозможность выбора нескольких конфигураций сразу, как я понял, принципиальное ограничение, и куда печальнее.

                                А вообще, у вас отличнейшая IDE получается. Code model тот же куда лучше KDevelop 4 (а на пятый я до сих пор не перейду на основной машине, он падает постоянно), рефакторинги всякие, прелесть прямо.
                                  0
                                  Конфигурации можно запускать по несколько. Есть 'Before Run' — в настройках конфигурации и там можно Run another configuration выбрать.
                          +1
                          А теперь вопрос на миллион — возможность указать кастомную папку для билда в симейк-проектах, которую у вас на трекере просили чуть ли не с первого релиза, сделали? В роадмапе было, и этого я точно ждал больше всего остального — blog.jetbrains.com/clion/2016/03/clion-2016-2-roadmap (см. «Ability to specify the build/generation output directory»)
                            0
                            Не успели, к сожалению. По CMake много спланировали, но ресурсов не хватило. Но фича в самых ближайших планах.
                              +1
                              Вот прямо поддержу. Реально раздражает что при старте CLion пытается собрать проект во временной папке Windows в разделе пользователя, а там — оп кириллические символы и всё ломается. Пришлось сделать отдельную учётку. Почему нельзя сделать ключик — использовать такой-то путь для временных файлов/сборок?
                                +2
                                Можно поменять IDE system path в качестве воркэраунда пока.
                                  0
                                  Спасибо огромное! Я так и не смог придумать запрос в поисковик по этому вопрос :)
                                    0
                                    Да, наверное это не легко. Согласна. Наш недочет. Мы поэтому добавили ссылку на вокрэраунд вот сюда
                              0
                              >Множество проблем было решено (в частности, та самая с command timeout)
                                0
                                Тоже сталкивался с этим багом (весьма раздражающим). Чем именно он был вызван? Потому что проблема появлялась иногда и непонятно, что именно её тригерило. Например, мой код перестал дебажиться после того, как я перенёс определения методов из .h в .cpp.
                                  0
                                  Там много разных причин было: и не совсем корректная обработка ошибок дебаггера в драйвере, и проблемы с производительностью, и др. Мы довольно серьезно переделали оба драйвера (и для GDB, и для LLDB). Попробуйте и поделитесь с нами, стало ли лучше дебажиться с новой версией.
                                0
                                На сколько я понимаю вы хотели делать все IDE на Kotlin. CLion написан на Kotlin, или таки C++?
                                  +2
                                  CLion, как и другие наши IDE на базе IntelliJ-платформы написан на Java и Kotlin.
                                    0
                                    Странный вопрос. Есть core, есть плагины есть специфика для языка и языковых инструментов.
                                    Core на Java. Остальное на чем угодно может быть. Хоть на каком-нибудь внутренней языковой абстракции поверх Java.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      +2

                                      Держите нас в курсе

                                        0
                                        Расскажете, почему не рассматривали и почему выбрали?
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Я в восторге от поддержки Doxygen, особенно от возможности вызвать справку из диалога автодополнения.
                                          0
                                          Ух, удаленная отладка это очень здорово! Спасибо за здоровскую IDE!

                                          Кстати, есть какте-то новости или подвижки в сторону add_custom_target?
                                            0
                                            Спасибо!

                                            Мы не успели заняться этой задачей к этому релизу, но планируем постараться успеть к следующему. По CMake довольно много сейчас важных задач в очереди. Эта в частности.
                                            0
                                            Кстати, по поводу форматирования. Вот чесслово, очень лениво расставлять галочки :) У меня форматированием занимается astyle, в любых средах/редакторах. Без каких-либо ключей или дополнительных настроек, ибо есть ~/.astylerc. Оно, конечно, повешено и в External Tools, и в pre-commit hook. Но можно ли заменить стандартный форматёр, или хотя бы повесить на те же хоткеи — непонятно.
                                              +1
                                              Такой возможности сейчас нет. Можно закинуть фича реквест в трекер.

                                              У нас прошлым летом во время Хакатона в разработке был интересный плагин — он умел вытаскивать стиль форматирования из отформатированного кода и соответственно сохранять его в наших настройках. К сожалению, дальше Хакатона дело не ушло, и сейчас плагин в нерабочем состоянии. Но может, мы как-то попробуем его оживить.
                                                0
                                                Да на самом деле хватило бы и возможности назначать хоткеи для External Tools. Насколько понимаю, этого нет вообще? Просто ещё не разобрался, присматриваться к CLion начал только после появления внятных релизов перлового плагина, то есть не так давно :)

                                                > вытаскивать стиль форматирования из отформатированного кода

                                                IMHO, осмысленней было бы вытаскивать стиль из файлов настроек: indent, astyle, bcpp и т.д.
                                                  0
                                                  Из отформатированного кода — это все же более общий случай. А главное — это дало нам возможность добавить целый список заготовленных стилей — Google, GNU, Qt, и другие (вот с этим релизом еще LLVM и LLDB добавили).

                                                  > Да на самом деле хватило бы и возможности назначать хоткеи для External Tools. Насколько понимаю, этого нет вообще?
                                                  Есть. Идете в настройки Keymap. Там поиском находите external tools в списке и добавляете шорткат.
                                                    0
                                                    >Из отформатированного кода — это все же более общий случай

                                                    Я б сказал, что это разные юзкейсы. Но в любом случае вещь эта одноразовая, при первой настройке среды. И вполне компенсируется внешними утилитами.

                                                    > это дало нам возможность добавить целый список заготовленных стилей

                                                    Наверное, это полезно, если ты работаешь в гугле или в Qt :) На практике же ещё ни разу не встречал твёрдого и побуквенного следования определённому стилю. Везде есть хоть какие-то детали. Самой распространённой базой в том, что встречал, является, как ни странно, Stroustrup style (-A4 в ключах astyle). Хотя речь идёт именно о pure C, а не C++! Даже в низкоуровневом C, где, по идее, Торвальдс — абсолютный авторитет, он вполне катит.
                                                      0
                                                      Stroustrup тоже есть. Соб-но, да, идея в том, что можно выбрать предопределенный стиль, и на его базе сконфигурировать нужный пользователю.
                                                        0
                                                        Ну да. Моя мысль в том, чтобы пойти дальше и отказаться от ненужных шагов в принципе :)
                                                          0
                                                          Не очень понятно, почему они ненужные.
                                                            0
                                                            См. ниже про usecases. Если есть готовый конфиг, почему бы не использовать его? Это ж в любом случае «одноразовые» вещи, на уровне «настроил и забыл».

                                                            С другой стороны, ползание по менюшкам — обязательная часть освоения среды, наравне с читанием манов :) Но раз уж и на это забивают (посмотрел в зеркало)…
                                                    0

                                                    Это всё с нуля делалось? CLion ведь Clang использует? Есть ведь ровно такой же инструмент — clang-format. И заготовленные стили там есть (LLVM, Google, Chromium, Mozilla, WebKit), на основе которых тоже можно свой конфиг делать.


                                                    @kloppspb, рекомендую взглянуть на инструмент, кстати. У него информации о структуре кода больше, чем у astyle/indent, поэтому чаще адекватнее форматирует.

                                                      0
                                                      Платформе, в которой это все реализовано, уже более 16 лет, так что с нуля в CLion, конечно, оно не делалось. Добавлялась специфика для C/C++, это да.

                                                      А clang-format мы думаем заинтегрировать к себе
                                                        0
                                                        Я в курсе. Речь на об «адекватности», а о том, что в каждой избушке свои погремушки. Да, все мы читали про красоту исходников Doom3 :) Но на практике приходится встречать всякие извраты, от пресловутых табов/пробелов, до «звёздочку прижимаем к имени, амперсанд нет». И основная идея в том, чтобы засосать чужой исходник и моментально форматнуть его в приятное глазу. Но вот с обратным преобразованием — проблемы, да… Тут либо должен быть чёткий гайд (в идеале — конфиг конкретной утилиты), либо эвристика.
                                                          0
                                                          до «звёздочку прижимаем к имени, амперсанд нет»

                                                          Вот вы прям мой личный кодстайл описали.

                                                +3
                                                Будет ли вестись какая-нибудь работа по оптимизации IDE? Я понимаю, что Java и всё такое, но уж слишком прожорлив Clion (да и не только Clion).
                                                  –3

                                                  О какой прожорливости вы говорите?

                                                    +1
                                                    Оптимизациями мы, конечно, заняты постоянно. И по памяти, и по производительности. Но если разбираться чуть менее абстрактно, то что именно вас беспокоит? И на каком проекте? Присылали ли вы нам логи/дампы, чтобы мы посмотрели, проверили, что нет каких-то ошибок/утечек/фризов?
                                                      –3
                                                      У меня рабочая машина — двухъядерный старичок Lenovo B570. С 12 Gb памяти, из которых половина отведена на /tmpfs. Принципиальной разницы между работой в JB и Eclipse не вижу. Ну, там другие проблемы. Они тебе не понятны, пока папа ремнём по заднице не попал.
                                                      +2
                                                      Прошу прощения за некропостинг, но ведутся ли какие-нибудь работы по интеграции clang'овского парсера, а не Вашего самопального? Clang имеет на порядок лучшую поддержку C++, и я думаю многие согласятся с тем, что свой велосипед тут писать не совсем уместно.
                                                      Вот этот issue: https://youtrack.jetbrains.com/issue/CPP-81
                                                        +2
                                                        Давайте по порядку.

                                                        Во-первых, этот ишью не про то. А про интеграцию clang анотатора. То есть, чтобы ошибки, которые умеет детектить clang, показывать как часть встроенных code inspections. Так в AppCode сейчас сделано для Objective-C и для Swift (там SourceKit).

                                                        Во-вторых, про clang парсер. Мы бы и рады не писать велосипед, но к сожалению, в текущем состоянии clang не подходит, чтобы решить все задачи, которые IDE ставит парсеру. Почему?
                                                        1. IDE должна работать с некорректным и неполным кодом, то есть в отличие от парсера должна восстановить дальнейший парсинг после нахождения ошибки.
                                                        2. У IDE и компилятора разные требования к знаниям о путях, по которым находятся те или иные сорс-файлы (у компилятора они ниже).
                                                        3. IDE необходимо знание о всем проекте. Например, чтобы иметь рефакторинг, который работает на всем проекте, а не только на открытом файле, нужен project-wide кэш символов.
                                                        4. Все это добро должно работать инкрементально, чтобы IDE имела приемлемую производительность.

                                                        Наверное, если бы мы несколько лет назад начали работу именно с того, что допилили в clang все, чего нам не хватает, это бы решило проблему (хотя у нас нет четкой уверенности, что там легко можно все нужное реализовать — мы честно изучали вопрос). Но тогда clang еще был слишком молод. Сейчас он гораздо более «дружелюбен» к IDE, конечно.

                                                        В тоже время, у нас в компании накоплена 16-летняя экспертиза по написанию такого рода инструментов, есть архитектура, в которую наше решение встраивается легко и команда, которая с интересом этим занимается (и при этом следит за развитием clang-а и clang-based инструментов).

                                                        Надеюсь, что смогла ответить на ваш вопрос.
                                                        0

                                                        Друзья, а есть ли какие-нибудь новости про плагин CLion для IDEA? Уж очень мне нравится, как у меня сейчас разработка для python/go/ruby/php в одной среде идёт :)

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

                                                            Спасибо, подписался

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

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