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

Чуть больше года прошло с момента первого релиза нашей кросс-платформенной 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
Поделиться с друзьями
-->

Комментарии (73)


  1. kloppspb
    20.07.2016 18:01
    +1

    Valgrind по-прежнему только в планах?


    1. anastasiak2512
      20.07.2016 18:10

      Да, руки пока до него не дошли. Но мы про него помним.


      1. kloppspb
        20.07.2016 18:28

        Ы-ы-ы, обновился — слетел честный тичерский ключ…


        1. anastasiak2512
          20.07.2016 18:29

          Попробуйте ввести заново. Заработает?


          1. kloppspb
            20.07.2016 18:36

            Подхватился, OK. Погоняю :)


            1. anastasiak2512
              20.07.2016 18:37
              +1

              Отлично. Извините за неудобства.


        1. grossws
          20.07.2016 19:13

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


          1. moscas
            21.07.2016 12:42

            Сейчас это as designed, но с переходом на подписки перестало быть логичным: поменяем.


  1. victor1234
    20.07.2016 18:12

    Вы планируете сделать поддержку тонкого клиента? Когда на локальной машине работает только легкий интерфейс, а все остальное на удаленной? И улучшить vim-плагин?


    1. anastasiak2512
      20.07.2016 18:24
      +1

      > Вы планируете сделать поддержку тонкого клиента? Когда на локальной машине работает только легкий интерфейс, а все остальное на удаленной?

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

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

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

      А что именно хотелось бы улучшить? У нас есть трекер плагина — закидывайте туда свои идеи, если они еще не там.


  1. Holms
    20.07.2016 19:19

    Как насчет поддержки managed-C++?


    1. Nagg
      20.07.2016 20:47
      +1

      Visual Studio + Resharper++


      1. Holms
        20.07.2016 20:58

        и в подметку не годится по сравнению с C# + R# :(


    1. anastasiak2512
      20.07.2016 22:40

      Нет в планах, так как, как верно было замечено, для этих целей есть ReSharper C++. А что именно в нем не устраивает?


      1. anastasiak2512
        21.07.2016 20:02

        Меня тут поправили, что ReSharper C++, к сожалению, тоже не умеет. Пока по-крайней мере


  1. Alex_ME
    20.07.2016 19:32

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

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


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

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


    1. anastasiak2512
      20.07.2016 22:44

      Например, здесь.
      Суть в том, что, когда вы создаете файл через create new class/source file/header file, в диалоге создания файла CLion предлагает обновить таргеты и даже показывает те, которые по его мнению подойдут.


  1. Daffodil
    20.07.2016 19:43
    +3

    Очень хочется поддержку других билд-систем. Или хотя бы ручную настройку проекта как в Eclipse. Переносить всё на CMake не вариант.


    1. anastasiak2512
      20.07.2016 22:45

      Понимаю. Но пока у нас ресурсы до этого не доходят. Есть еще куча всего по CMake, что надо сначала доделать.


  1. halyavin
    20.07.2016 20:42
    +2

    А несчастному разработчику, который героически исправляет 261 баг парсинга C++, вы молоко за вредность даёте?


    1. anastasiak2512
      20.07.2016 22:49
      +3

      Он не один там, к счастью. Сейчас несколько человек работают над языковыми фичами.


  1. Falstaff
    20.07.2016 21:02
    +2

    Пользуясь случаем, спрошу: есть возможность полностью выключить диагностику на участке кода? Прагмами, например? Использую пару библиотек, полных шаблонной магии и C++14, код местами весь красный. Вообще, интересно было бы узнать планы по улучшению поддержки языка.


    1. anastasiak2512
      20.07.2016 22:52
      +1

      C++14 пока не поддерживается, но на какие-то изменения в этом направлении надеемся уже в следующем релизе. Более точно планы озвучим чуть позже в блоге.
      Инспекшены можно отключать через правую клавишу в меню квик-фиксов, но это не работает если проблема в парсере (красный код).


      1. kloppspb
        21.07.2016 13:56
        +1

        И тут непонятно что происходит: http://xxo.su/resizer/i/e/4/6102b63f.png
        Эклипс и прочие Code::Block с кодлайтами этот фрагмент парсят без проблем.


        1. anastasiak2512
          21.07.2016 14:17

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


          1. kloppspb
            21.07.2016 14:25

            Это не «проект» в общем понимании. Этот файл — промежуточный результат при компиляции kernel module, и в состав проекта не входит. Но иногда хочется посмотреть что там наавтогенерилось, вот и открываю его в том же редакторе. А там всё такое красное :)

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


            1. anastasiak2512
              21.07.2016 15:15

              Похоже там какие-то проблемы с __used (он даже не подкрашен судя по скриншоту). А можете сделать go to dedclaration на __used? Куда будет осуществлен переход?


              1. kloppspb
                21.07.2016 15:23

                Никуда. А определение на самом деле в файле <linux/compiler.h>, который там включается явно, сверху третьей строчкой (да и неявно из <linux/module.h> в первой же строке). И определение это пустое :) То есть тупо "#define __used /* unimplemented */".


                1. anastasiak2512
                  21.07.2016 15:58

                  ок, мы завели багу — попробуем воспроизвести на своей стороне и будем изучать/править. Спасибо!


                  1. kloppspb
                    21.07.2016 16:09

                    Файл закинуть? BTW, проблемы начинаются ещё раньше: http://xxo.su/resizer/i/8/7/a5868f0.png. При попытке прыгнуть на определение MODULE_INFO выдаёт «Cannot find declaration to go» (находится оно в <linux/module.h>).


                    1. anastasiak2512
                      21.07.2016 18:03

                      Если можете, закиньте, пожалуйста.


  1. 0xd34df00d
    20.07.2016 21:32
    +3

    А семантическую раскраску сделайте, пожалуйста!

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


    1. anastasiak2512
      20.07.2016 22:55

      Семантическая раскраска в разработке. Не могу пока пообещать, когда что-то готовое сможем показать, но надеюсь — скоро.

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


      1. 0xd34df00d
        21.07.2016 02:12
        +1

        Про таргеты лучше пояснить на примере.

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

        Скрин
        image


        1. anastasiak2512
          21.07.2016 10:15

          CLion для любого таргета в CMake по умолчанию сгенерирует вам конфигурацию. Ее имя будет совпадать с именем таргета. Дальше вы также можете выбирать конфигурацию и запускать ее. Видимо главная сложность, что эти конфигурации не привязаны к дереву файлов в project view. Так?


          1. 0xd34df00d
            21.07.2016 18:35

            Основная сложность в том, что я могу выбрать только одну конфигурацию. В том же kdevelop я могу выбрать произвольное число таргетов (он конфигурациями не оперирует) и собирать их в произвольном порядке (с учётом описанных в cmake зависимостей, конечно). В CLion я не могу выбрать больше одной конфигурации.

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

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

            А вообще, у вас отличнейшая IDE получается. Code model тот же куда лучше KDevelop 4 (а на пятый я до сих пор не перейду на основной машине, он падает постоянно), рефакторинги всякие, прелесть прямо.


            1. anastasiak2512
              21.07.2016 22:49

              Конфигурации можно запускать по несколько. Есть 'Before Run' — в настройках конфигурации и там можно Run another configuration выбрать.


  1. CyrusVorazan
    20.07.2016 21:51
    +1

    А теперь вопрос на миллион — возможность указать кастомную папку для билда в симейк-проектах, которую у вас на трекере просили чуть ли не с первого релиза, сделали? В роадмапе было, и этого я точно ждал больше всего остального — blog.jetbrains.com/clion/2016/03/clion-2016-2-roadmap (см. «Ability to specify the build/generation output directory»)


    1. anastasiak2512
      20.07.2016 22:57

      Не успели, к сожалению. По CMake много спланировали, но ресурсов не хватило. Но фича в самых ближайших планах.


    1. BlaDe39
      21.07.2016 13:03
      +1

      Вот прямо поддержу. Реально раздражает что при старте CLion пытается собрать проект во временной папке Windows в разделе пользователя, а там — оп кириллические символы и всё ломается. Пришлось сделать отдельную учётку. Почему нельзя сделать ключик — использовать такой-то путь для временных файлов/сборок?


      1. anastasiak2512
        21.07.2016 13:09
        +2

        Можно поменять IDE system path в качестве воркэраунда пока.


        1. BlaDe39
          21.07.2016 13:29

          Спасибо огромное! Я так и не смог придумать запрос в поисковик по этому вопрос :)


          1. anastasiak2512
            21.07.2016 13:36

            Да, наверное это не легко. Согласна. Наш недочет. Мы поэтому добавили ссылку на вокрэраунд вот сюда


  1. metopa
    20.07.2016 21:51

    >Множество проблем было решено (в частности, та самая с command timeout)


    1. metopa
      20.07.2016 23:45

      Тоже сталкивался с этим багом (весьма раздражающим). Чем именно он был вызван? Потому что проблема появлялась иногда и непонятно, что именно её тригерило. Например, мой код перестал дебажиться после того, как я перенёс определения методов из .h в .cpp.


      1. anastasiak2512
        20.07.2016 23:48

        Там много разных причин было: и не совсем корректная обработка ошибок дебаггера в драйвере, и проблемы с производительностью, и др. Мы довольно серьезно переделали оба драйвера (и для GDB, и для LLDB). Попробуйте и поделитесь с нами, стало ли лучше дебажиться с новой версией.


  1. ADR
    20.07.2016 21:51

    На сколько я понимаю вы хотели делать все IDE на Kotlin. CLion написан на Kotlin, или таки C++?


    1. anastasiak2512
      20.07.2016 22:58
      +2

      CLion, как и другие наши IDE на базе IntelliJ-платформы написан на Java и Kotlin.


    1. mamkaololosha
      20.07.2016 23:10

      Странный вопрос. Есть core, есть плагины есть специфика для языка и языковых инструментов.
      Core на Java. Остальное на чем угодно может быть. Хоть на каком-нибудь внутренней языковой абстракции поверх Java.


  1. Ivan_83
    21.07.2016 11:59
    -4

    Выбирал в начале года IDE.
    Всё не свободное и всё на джаве даже не рассматривал.
    Остановился на CodeLite.


    1. Randl
      21.07.2016 12:54
      +2

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


    1. philipto
      21.07.2016 14:47

      Расскажете, почему не рассматривали и почему выбрали?


      1. Ivan_83
        22.07.2016 00:09

        Если бы не нашлось ничего прилично без джава и денег то в начале посмотрел бы эклипс.
        Джава не хочу, лишнее барахло в системе и наслышан о тормозах.

        CodeLite всем устроил: притянул минимум зависимостей, есть всё что хотелось и даже больше, но при этом не перегружен.
        Автодополнение, интеграция с gbd, вроде удалённая отладка тоже есть — не пробовал, интеграция с git, svn, cppchech, valgrind, cmake, заливка=синхронизация по ssh и пр.
        Ещё Анюту смотрел, она выглядит сильно проще.
        Вроде что то ещё пробовал, но тоже не понравилось.


  1. RPG18
    21.07.2016 15:18

    Я в восторге от поддержки Doxygen, особенно от возможности вызвать справку из диалога автодополнения.


  1. dir94
    21.07.2016 20:53

    Ух, удаленная отладка это очень здорово! Спасибо за здоровскую IDE!

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


    1. anastasiak2512
      21.07.2016 22:47

      Спасибо!

      Мы не успели заняться этой задачей к этому релизу, но планируем постараться успеть к следующему. По CMake довольно много сейчас важных задач в очереди. Эта в частности.


  1. kloppspb
    21.07.2016 23:28

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


    1. anastasiak2512
      21.07.2016 23:35
      +1

      Такой возможности сейчас нет. Можно закинуть фича реквест в трекер.

      У нас прошлым летом во время Хакатона в разработке был интересный плагин — он умел вытаскивать стиль форматирования из отформатированного кода и соответственно сохранять его в наших настройках. К сожалению, дальше Хакатона дело не ушло, и сейчас плагин в нерабочем состоянии. Но может, мы как-то попробуем его оживить.


      1. kloppspb
        21.07.2016 23:38

        Да на самом деле хватило бы и возможности назначать хоткеи для External Tools. Насколько понимаю, этого нет вообще? Просто ещё не разобрался, присматриваться к CLion начал только после появления внятных релизов перлового плагина, то есть не так давно :)

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

        IMHO, осмысленней было бы вытаскивать стиль из файлов настроек: indent, astyle, bcpp и т.д.


        1. anastasiak2512
          22.07.2016 00:15

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

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


          1. kloppspb
            22.07.2016 01:19

            >Из отформатированного кода — это все же более общий случай

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

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

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


            1. anastasiak2512
              22.07.2016 09:33

              Stroustrup тоже есть. Соб-но, да, идея в том, что можно выбрать предопределенный стиль, и на его базе сконфигурировать нужный пользователю.


              1. kloppspb
                22.07.2016 16:00

                Ну да. Моя мысль в том, чтобы пойти дальше и отказаться от ненужных шагов в принципе :)


                1. anastasiak2512
                  22.07.2016 16:02

                  Не очень понятно, почему они ненужные.


                  1. kloppspb
                    22.07.2016 16:26

                    См. ниже про usecases. Если есть готовый конфиг, почему бы не использовать его? Это ж в любом случае «одноразовые» вещи, на уровне «настроил и забыл».

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


                    1. anastasiak2512
                      22.07.2016 16:44

                      Ага, спасибо.


          1. JIghtuse
            22.07.2016 10:46

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


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


            1. anastasiak2512
              22.07.2016 14:27

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

              А clang-format мы думаем заинтегрировать к себе


            1. kloppspb
              22.07.2016 16:07

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


  1. ZaMaZaN4iK
    23.07.2016 16:51
    +3

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


    1. RPG18
      24.07.2016 13:30
      -3

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


    1. anastasiak2512
      24.07.2016 23:27
      +1

      Оптимизациями мы, конечно, заняты постоянно. И по памяти, и по производительности. Но если разбираться чуть менее абстрактно, то что именно вас беспокоит? И на каком проекте? Присылали ли вы нам логи/дампы, чтобы мы посмотрели, проверили, что нет каких-то ошибок/утечек/фризов?


    1. kloppspb
      27.07.2016 22:53
      -3

      У меня рабочая машина — двухъядерный старичок Lenovo B570. С 12 Gb памяти, из которых половина отведена на /tmpfs. Принципиальной разницы между работой в JB и Eclipse не вижу. Ну, там другие проблемы. Они тебе не понятны, пока папа ремнём по заднице не попал.