- PVSM.RU - https://www.pvsm.ru -
Привет! Год потихоньку подходит к концу, кто-то уже готовится к праздничным мероприятиям, а кто-то еще старается завершить все задуманное. А мы вот выпустили третий за этот год релиз нашей кросс-платформенной IDE для разработки на C и C++. Оглядываясь назад (и подводя итоги, как принято делать накануне нового года), нам кажется, что за 2016 год CLion существенно вырос и стал гораздо более зрелым:
Мы старались прислушиваться к нашим пользователям (насколько это было возможно) и ориентироваться на их запросы. Версия 2016.3 не стала исключением и принесла множество долгожданных улучшений:
А теперь обо всем по порядку.
Как вы, наверное, знаете (ведь у нас это спрашивают в комментариях под каждым постом про CLion), в CLion мы полагаемся на свой парсер [2], и активная работа над ним не затихает ни на минуту. В этот раз из существенных доработок стоит отметить несколько.
Во-первых, это поддержка пользовательских литералов. Мы долгое время не брались за эту задачу, но возрастающая популярность концепции встроенного типа и появление ее использований в std::chrono и других частях стандартной библиотеки привели нас к необходимости ее поддержки. Стоит отметить, что помимо уменьшения количества false-positive ошибок анализатора кода (которые были вызваны отсутствием поддержки пользовательских литералов) и всплывающего окна Quick Documentation (Ctrl+Q
на Lin/Win, F1
на macOS), которое теперь корректно отражает тип, CLion также позволяет переименовывать литералы, обновляя определение и все его использования:
Раз уж речь зашла об операторах, стоит отметить, что CLion умеет теперь искать случаи использования перегруженных операторов (кроме new и delete), что может быть особенно полезно при знакомстве с новым и неизвестным кодом, активно использующим эту возможность языка:
Еще одна причина множественных ошибок встроенного анализатора кода, которая была устранена в этом релизе, — исправления в поддержке overload resolution. Теперь CLion может правильно выбрать подходящего кандидата, а значит правильно показать неиспользуемый код, найти все использования, переименовать функцию или изменить ее сигнатуру, и т.д. А вместе с этим, среда разработки теперь укажет вам на ambiguous call или отсутствие подходящей функции для вызова — соответствующие инспекции добавлены в CLion 2016.3:
В целом наша команда расширилась, и в частности у нас появилось больше людей, занимающихся анализом кода. Благодаря этому релиз 2016.3 принес множество изменений в этой области. Например, анализ, полагающийся на вычисления sizeof(), стал платформо-зависимым. Мы также поправили ошибочное предупреждение о неиспользуемой переменной в случае нетривиального деструктора (что особенно важно для так называемой ‘guard’ idiom):
Кроме того, CLion теперь понимает и корректно учитывает __attribute__(unused) и __builtin_unreachable при анализе кода. И это лишь несколько примеров из множества улучшений статического анализа кода, попавших в CLion 2016.3.
Важным шагом в дальнейшем развитии языковой поддержки можно считать появление поддержки разделителя разрядов (C++14). Мы надеемся, что в дальнейшем мы сможем уделить время и другим возможностях новейших стандартов языка C++. Если вы захотите обратить наше внимание на что-то конкретное, рекомендуем голосовать за соответствующие задачи в нашем трекере [3].
Наши пользователи вполне резонно замечали, что поддержка чистого C в CLion немного хромает. Мы наконец решили это исправить и добавили поддержку gcc atomic builtins и ключевого слова _Generic, а для ключевых слов _Thread_local, _Alignas, _Noreturn, _Static_assert, and _Atomic, которые появились еще в обновлениях к версии 2016.2, в этой версии появилась возможность автодополнения для ускорения процесса написания кода:
Кто-то может здесь вспомнить, что в этой версии планировалось добавить шаблоны проектов, в частности для C проекта. Вынуждены честно признать, что работа ведется, но пока не закончена. Но уже в одном из ближайших обновлений 2016.3.x шаблоны появятся.
Этим изменениям предшествовало множество споров и обсуждений. Наш изначальный подход, к сожалению, не устроил многих. Объективная критика активно копилась в трекере. Так, например, запрос про изменение директории, в которой происходит генерация CMake, собрал ~90 голосов и ~90 комментариев. В блоге, в твиттере, вживую на разнообразных конференциях и выставках мы не раз обсуждали проблемы с производительностью, вызванные тем, что CLion собирал все четыре конфигурации CMake для каждого проекта (Debug, Release, RelWithDebInfo, MinSizeRel). И вот, наконец, в версии 2016.3 мы существенно переработали подход и предложили решение накопившихся проблем.
Теперь CLion собирает только выбранную конфигурацию. Данная настройка, как и путь к директории, где требуется производить генерацию, находится в диалоге проектных настроек Build, Execution, Deployment | CMake. По умолчанию проект собирается в директории внутри исходных кодов проекта с именем cmake-build-debug. В будущем мы планируем дать возможность пользователям изменять и значения по умолчанию (например, чтобы указать директорию для сборки, общую для всех ваших проектов).
Благодаря этим изменениям стало также возможным открывать проект из директории, где уже произведена генерация CMake, без повторного вызова CMake, что существенно экономит время на открытие проекта. Для открытия проекта достаточно указать директорию сборки или файл CMakeCache.txt:
Обращаем внимание, что это пока работает только в случае, когда в качестве генератора использовались Makefiles. В противном случае CLion вызовет перегенерацию CMake.
CMake, как известно, система не самая простая, особенно для новичков. Для упрощения отладки скриптов CMake мы добавили возможность видеть логи вызова CMake команды в окне CMake. А вот редактор CMake Cache был убран. Вместо него среда разработки открывает CMakeCache.txt файл прямо в редакторе, что дает возможность легко добавлять новые значения. В следующих релизах мы планируем обучить CLion “языку” CMake Cache файлов, чтобы сделать работу с ними быстрее и удобнее.
В прошлом релизе [4] мы добавили возможность отлаживать из CLion приложения, запущенные на удаленной машине из-под GDB-сервера. Правда, не все комбинации локальной и удаленной платформ были доступны. Релиз 2016.3 принес возможность удаленно отлаживать с платформы Windows:
Кстати, помимо удаленной отладки, в отладчике произошло целое множество исправлений. Так, например, CLion более не перезаписывает переменную окружения PYTHONPATH, что в частности позволяет отлаживать С-расширения для Python (Python C extension modules).
Еще одна долгожданная возможность — семантическая подсветка! Сразу скажу, как включить: идем в настройки Editor | Color & Fonts | Language Defaults, находим там группу Semantic highlighting и ставим галочку Unique color for each parameter and local variable. Дальше можно настраивать цветовые диапазоны по собственному усмотрению или воспользоваться значениями по умолчанию.
Семантическая подсветка придумана, чтобы лучше понимать, как поток данных изменяется в процессе исполнения вашей программы. Для этого все переменные и параметры красятся (по-возможности) в разные цвета.
Как это работает в CLion:
Ну, а выглядит это примерно так:
Еще одно изменение, связанное с подсветкой кода, это автоматическое переключение resolve-контекста в редакторе при смене конфигурации. Давайте разберемся, зачем это может быть нужно.
Представьте себе ситуацию, что файл с исходными кодами включен в сборку двух разных таргетов CMake. При этом настройки у этих таргетов отличаются, а в самом коде встречаются блоки условной компиляции, зависящие от этих настроек. Как же быть редактору кода в такой ситуации? Как правильно подсветить эти части кода, как искать случаи использования, как производить корректные рефакторинги кода? Ответ прост: выбрать настройки какого-то одного таргета и их использовать. Но какого? Нам представляется логичным, что того, над которым вы сейчас работаете и который собираете/отлаживаете в данный момент времени. Поэтому при переключении Run/Debug конфигурации, CLion 2016.3 автоматически переключает и resolve-контекст для файла:
Если все же это не то, чего вам хочется, воспользуйтесь ручным переключением resolve-контекста в правом нижнем углу редактора. Автоматическое переключение в таком случае будет отключено до следующего перезапуска IDE (но это скорее пока баг [6], чем фича).
Здесь на Хабре уже было несколько обсуждений разработки игр с использованием Unreal Engine в CLion. В рамках данного релиза мы решили посмотреть, как мы можем помочь пользователям в этом случае. А поводом стало появление стороннего плагина [7] для Unreal Engine, который позволяет открыть проект в CLion, сгенерировав для него необходимые CMake-скрипты. Мы попробовали этот плагин и были приятно удивлены тем фактом, что получаемый CMake позволяет CLion быстрее проиндексировать проект, так как включает не все исходные коды игрового движка, а только необходимую часть.
Обрадовавшись, мы существенно уменьшили [8] время повторного переоткрытия уже проиндексированного проекта в CLion. А также наш коллега добавил плагин [9] для автодополнения спецификаторов рефлекшена:
Подробный пост о том, как можно разрабатывать игры на базе Unreal Engine в CLion, можно прочитать в нашем блоге [1].
В релизе CLion 2016.3 есть еще множество других изменений и правок, но, чтобы не затягивать, мы упомянем их лишь коротко:
Ниже короткое демо на английском от Фила Нэша, нашего девелопер-адвоката:
В общем, если вам стало интересно и вы хотите попробовать новую версию, как обычно, есть 30-дневная бесплатная пробная версия [11], а в разделе цен [12] можно узнать о стоимости подписки.
Следите также за статьями и обновлениями в нашем англоязычном блоге [13]. Мы будем рады ответить на любые ваши вопросы в комментариях.
Ваша команда JetBrains CLion
The Drive to Develop
Автор: JetBrains
Источник [14]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/212980
Ссылки в тексте:
[1] целый отдельный пост: https://blog.jetbrains.com/clion/2016/10/clion-and-ue4/
[2] свой парсер: https://blog.jetbrains.com/blog/2015/08/06/jetbrains-way-to-cpp-the-inside-story-of-our-journey/#parser
[3] трекере: https://youtrack.jetbrains.com/issues/CPP
[4] прошлом релизе: https://blog.jetbrains.com/clion/2016/07/clion-2016-2-eap-remote-gdb-debug/
[5] в нашем блоге: https://blog.jetbrains.com/clion/2016/11/clion-2016-3-eap-remote-gdb-debug-udl-rename-and-code-analysis-fixes/#remote_debug
[6] баг: https://youtrack.jetbrains.com/issue/CPP-7640
[7] стороннего плагина: https://github.com/dotBunny/CLionSourceCodeAccess
[8] уменьшили: https://youtrack.jetbrains.com/issue/CPP-7012
[9] плагин: https://plugins.jetbrains.com/plugin/7753?pr=clion
[10] San Francisco: https://developer.apple.com/fonts/
[11] бесплатная пробная версия: https://www.jetbrains.com/clion/download/
[12] разделе цен: http://www.jetbrains.com/clion/buy/
[13] англоязычном блоге: https://blog.jetbrains.com/clion/
[14] Источник: https://habrahabr.ru/post/315962/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.