company_banner

JetBrains C++ night: впечатления и записи докладов

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

    Буквально на днях мы выпустили очередной релиз CLion 2016.1, нашей кросс-платформенной IDE для разработки на C и C++. Передохнув от релизной суматохи, хотим поделиться впечатлениями о проведенном недавно нами мероприятии, посвященному разработке на C++.

    24 февраля этого года в офисе компании JetBrains собралось более 50 человек на мероприятие JetBrains C++ night. Основную часть аудитории составляли C++ разработчики из питерских и не только IT-компаний.

    Хотя большую часть времени заняли доклады наших разработчиков, видеозаписи которых опубликованы на нашем канале (см. ссылки ниже), нашей основной целью было неформальное общение с C++ сообществом, которое есть в Питере или приехало поучаствовать в конференции C++ Russia.

    В целом, нам кажется, что первый блин вышел не комом, хотя нам есть над чем работать. Главное, нам удалось пообщаться, узнать много интересного, услышать множество пожеланий и вопросов к нашим продуктам, да и просто понять, какой же разработкой занимаются в C++ мире в Питере и в России вообще. Так, например, мы неожиданно для себя получили запрос на поддержку Android проектов на CMake (Android Studio, в которую включена поддержка C++ на базе CLion, CMake не поддерживает; а CLion в свою очередь не имеет сейчас Android поддержки).

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

    • Большая часть узнала о мероприятии из анонса на Хабре.
    • Общий рейтинг мероприятия получился 4,875 (из 5). Нам кажется, что это отличный показатель для первого раза!
    • Почти все пришедшие используют С++11, примерно половина C++14, буквально несколько человек робко подняли руки при вопросе о C++17.


    Разработчики JetBrains представили на мероприятии три доклада о C++ и связанных с ним технологиях и инструментах. Сегодня мы рады поделиться записями этих докладов с вами.

    Иван Сорокин, “Оптимизация ReSharper C++”
    Производительность — это ли не главный вопрос к разработчикам IDE? Команда ReSharper C++ рассказала про методы, использованные для ускорения работы IDE. Грубо говоря, их можно разделить на 3 категории: кеширование, ленивое вычисление и инкрементальное обновление. Некоторые из этих оптимизаций оказали существенное влияние на структуру программы в целом. В этом докладе мы обсудили детали этих оптимизаций и их влияние на структуру программы.


    Мария Бабурина, “Виртуозное использование юнит-тестирования в CLion”
    Test Driven Development — подход сейчас очень популярный. Для C++ существует множество фреймворков. Самым популярным, пожалуй, является Google Test. Чем он хорош, и как получить максимум выгоды при минимуме усилий? Может ли IDE помочь в этом? В этом докладе мы прошлись по всему циклу создания, конфигурирования, запуска и анализа Google Test в CLion, выяснили, чем встроенный запуск тестов удобнее запуска через консоль, и как CLion и Google Test вместе помогают быстрее находить, локализовывать и анализировать проблемы в коде.


    Дмитрий Нестерук, “Технологии высокопроизводительных вычислений”
    В этом докладе мы узнали, как выжать из “железа” максимум производительности. Увидели, как можно ускорять код на уровне инструкций (SIMD, SSE/AVX), как пользоваться механизмами императивной и декларативной многопоточности и как производить вычисления на кластерах с помощью MPI.


    Если у вас появились какие-либо вопросы к нашим разработчикам (на темы докладов, или просто о наших продуктах), пишите! Мы с удовольствием на них ответим.

    С уважением,
    C++ команда JetBrains
    JetBrains
    Делаем эффективные инструменты для разработчиков

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

      0
      Давно хотел спросить.
      Скажите, есть ли планы усовершенствовать используемую в Clion code-model так, чтоб препроцессорный код валидировался/препроцессировался и т.д?
        0
        А Вы не могли бы пример привести? Не очень понятен use case. И чего хочется.
        +5
        Rust! Я хочу поддержки Rust! :)

        Хотя и плюсы выглядят весьма вкусно. KDevelop (особенно 5 версия) — великолепный инструмент для анализа и написания кода. Вот только ему очень не хватает инструментов рефакторинга, которые есть в CLion.

          +1
          Ребята вот делают плагин. Вероятно со временем его можно будет в CLion использовать (за сейчас не скажу, не уверена).
          +1
          Первая IDE на которую я подумывал пересесть с vim. Мне не хватило возможности удаленного редактирования кода (когда сами сорцы лежат на удаленном сервере и сборка с запуском происходят там же).
          Планируете запилить?
            +1
            У нас есть плагин под названием Remote Host Access, который умеет синхронизировать сорцы:

            +1
            Хочется сказать спасибо всей команде за организацию мероприятия. Мелкие недостатки в виде потерянных людей и очередями за кофе можно даже не учитывать :) Интересно было послушать про внутреннюю «кухню» разработки.

            Отдельное спасибо Дмитрию за прекрасный, расширяющий сознание рассказ и байки про «сервер в подвале» :)
              0
              Спасибо! Мы рады, что вам понравилось.
              А что там про потерянных людей было? Про внутреннюю кухню обязательно еще расскажем с удовольствием. У нас, например, есть в планах мысль поделиться тем, как DFA (Data Flow Analysis) в CLion сделан.
                0
                На входе часть людей не нашли в списках зарегистрированных (сам оказался таким), провели в итоге без проблем, но некую очередь на входе это создало :)

                Будет интересно послушать. На самом деле при общении по CLion больше всего удивило, что они не пересекаются с ReSharper по кодовой базе, хотя, казалось бы, делают схожие вещи.

                Жду следующего EAP по CLion :)
                  0
                  А вы когда регистрировались? Мы выгрузили списки на ресепшн в середине дня. Но регистрацию закрыли. Возможно, проблема была с этим связана.

                  Исторически, CLion основан на платформе IntelliJ, а ReSharper C++ на ReSharper-платформе. Поэтому, конечно, кодовая база разная. Но сейчас идет очень тесное общение командами, цель которого иметь одинаковый user experience в обоих инструментах. Рефакторинги, кодо-генерация, инспекции — все это должно по задумке работать примерно "одинаково".
                    0
                    Регистрировался в день анонса мероприятия на Хабре. Может быть "что-то пошло не так", бывает :) Например, на мероприятиях Softline людей часто теряют пачками, дело привычное :)
                    Причину "почему так" в деталях раскрывали на встрече, я помню. Просто сам факт был немного удивителен :)
                      0
                      Очень странно. Разузнаю, и попробуем исправиться) Спасибо.
                        0
                        Вам спасибо :) Больше встреч хороших и разных!
                0
                Рад что понравилось :)
                +1
                Коллеги, давно мечтаю использовать ваш продукт для работы над ядром операционной системы, но — всё никак. :( Скажите, есть ли какой-то шанс обойтись без cmake? Перетаскивать на него сборку трёхэтажной конструкции с библиотеками, шахматами и поэтессами — никакой мочи нет. Второй дурацкий вопрос — размеры шрифтов. Глаза уже не те, хочется пресет под крупные (18pt) шрифты. Если редактор ещё удаётся в этот режим загнать, то UI бастует. Звучит глупо, но это реально мешает жить. :(
                  0
                  Пока без CMake никак. Планируем делать и другие проектные модели, но пока руки не дошли.
                  Шрифт UI настраивается в Appearance & Behavior | Appearance — там можно переопределить дефолтовый шрифт и/или размер.
                    0
                    А как вы относитесь к способам вроде eax.me/clion-any-project?
                    Возможно, гораздо проще улучшить Import From Sources чтобы он начал использовать какую-то инофрмацию из других build-систем. Можно было бы даже попарсить запуски компиляторов, как это вроде делает eclipse. Собирать он, допусим, так не научится, а вот индексировать код должно быть проще.
                      0
                      Хорошо относимся)
                      Если серьезно, то такие варианты тоже рассматриваются. Там тоже есть определенные сложности.
                        0
                        Просто я ни разу не видел чтобы вы предлагали такой способ тем, кто жаловался на cmake. Не расстраивайте людей зря)
                          0
                          Когда мы говорим про API на проектную модель, это в общем оно и есть. Тут проблема в том, что просто запустить компилятор на файлах пользователя, этого не достаточно, чтобы правильно распарсить код.
                        0
                        На самом деле, в интернете есть скрипты, которые конвертируют разные форматы (например MSVC) в CMake. Я не ручаюсь за их качество, но они точно существуют. Другой вопрос — это синхронизация проектных моделей, тут может возникнуть некоторый дискомфорт.
                          –1
                          А зачем синхронизировать? Надо брать и переезжать на CMake.
                          Ну в если серьёзно, то обратная синхронизация не всегда нужна, а разобраться с 3,5 командами CMake которые расскажут про то откуда брать и что определять должно быть не сложно, был бы каркас. Так что лично мне кажется это самым разумным костылём, и я был бы очень рад если бы односторонняя конвертация была бы поддержана CLion насколько это воможно, даже пусть потом у этого не работал бы configure и build.
                          На заметку, вот тут список каких-то скриптов для конвертации: https://cmake.org/Wiki/CMake#Converters_from_other_buildsystems_to_CMake
                            0
                            Да, спасибо за идею. Возможно, если текущий функционал Import Project будет уметь какие-то скрипты запускать такие, будет не плохо. надо подумать.
                            Хотя по личному опыту, реальный проект на Makefile-ах в CMake переводили человеко-месяц ручками и никакие скрипты там не помогли. Правда при этом существенно полечили проблемы проекта. Что было ценно само по себе..

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

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