CLion от JETBRAINS. Как изменить версию языка в проекте?
Здравствуйте. Кто пользуется чудо продуктами от компании джетбрейинс. Помогите по вопросу.
При создании нового проекта, среда предложила выбрать версию языка (были предложены С90, С99, С++11, С++17 и другие версии). Я выбрал с++11.
далее, при написании кода, он отказывается компилироваться с ошибкой Ошибка компиляции: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]. Оказывается, тот код который использовал я, будет работать на версии С99, а в С++ не поддерживается.
Вопрос. Где изменить конфигурацию уже существующего проекта и изменить в нем версию языка, чтобы среда разработки запускала компилятор gcc (для СИ), а не g++ ?
Перекликал много кнопок, так и не нашел этих настроек.
Лучшие ответы ( 2 )
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:
JetBrains Clion — исправление кодировки
При выоводе кирилицы во встроенную консоль при запуске кода , вместо русского текста непонятные.
Визуальный редактор для продуктов JetBrains (IntelliJ IDEA, CLion, Rider EAP)
Хочу написать программу, которая будет работать в Windows и Linux операционных системах. Программа.
Как сменить версию Unity в созданном проекте
Хочу с Unity 5.6 перейти на 2017 без ручной сборки нового проекта. У меня все больше складывается.
Как изменить версию comctl32 в runtime: к чему привязана эта информация и как ее изменить
Она видимо привязана к загружаемому модулю, т.к. создавая из DllMain контролы, учитывается версия.
6044 / 2159 / 753
Регистрация: 10.12.2010
Сообщений: 6,005
Записей в блоге: 3
Сообщение было отмечено GpvpHoobastank как решение
Решение
Дисклеймер: не проверял.
Попробуйте открыть файл CMakeLists.txt и сделать следующее:
1) настройка project(project_name) . Замените на: project(project_name C)
2) настройка языкового стандарта set(CMAKE_CXX_STANDARD 11) замените на set(CMAKE_C_STANDARD 99)
3) Сделайте релоад проекта File -> Reload CMake Project
Как сделать clion на русском
Здравствуйте, Cyberax, Вы писали:
C>Вот не надо. Usability в IDEA лучше, чем во всех остальных редакторах. Нафиг скроллеры со стрелочками вообще нужны, когда есть клавиатура?
Пытаюсь привыкнуть (PyCharm). Пока идет плохо: запускается долго, рендеринг шрифтов плохой, предложение по улучшению кода левые, REPL кривоват. Пока не сдаюсь.
До этого пробовал Аптану — комфорт лучше, но баги с git-итеграцией достали.
Re: [ANN] CLion — JetBrains IDE
| От: | alex_public | |
| Дата: | 03.10.14 10:32 | |
| Оценка: | 11 (3) | |
Ну что же, поставил я данный продукт, поигрался и готов поделиться впечатлениями. Во-первых сразу же скажу, что у меня были связаны с ним большие ожидания, т.к. в области полноценных C++ IDE выбор очень небольшой (собственно только 3 продукта и могут бороться за первое место) и у каждого варианта есть свои недостатки. А судя по уровню IDEA можно было надеяться на прорыв именно в самой проблемой области (анализатор кода и всё из него следующее). Так вот если кратко, то CLion в общем то оправдал надежды в этой области, но совершенно неожиданно показал дикие (настолько, что для нас этот продукт сейчас не пригоден к использованию) провалы в других областях, вроде как тривиальных.
А теперь по порядку. И начать я хочу с набора вроде как неважных мелочей, чтобы потом не отвлекаться на них при обсуждение принципиальных вещей. И так мелкие огрехи:
1. Сразу бросилось в глаза, что CLion не сообщает Windows о том, что он умеет сам нормально работать с нестандартным DPI. В итоге винда его масштабирует как картинку — получаем размытость, что очевидно неприемлемо для IDE. Очень странно видеть такое у вроде как солидного продукта, в то время как даже мелкие бесплатные утилитки работают корректно. Более того, если для 32-ух битного приложения Windows позволяет указать опцию «не масштабировать» в свойствах exe файла в Проводнике, то для 64-ёх битного кода эта возможность заблокирована (кстати, кто-нибудь знает обоснование этого странного поступка MS?) и надо идти добавлять специальную строку в специальное место реестра (про которое далеко не все знают). Ну т.е. я проблему преодолел своими силами, но в целом дико видеть такое в солидном продукте.
2. Захотелось открыть файл и сразу поразился диалогу для этого. Он не просто совсем не стандартный, но похоже что и ещё не умеет видеть сеть (или я не увидел где это включается?).
3. Про неудобные полосы прокрутки (в которые ещё фиг попадёшь мышкой) тут уже вроде писали. Впрочем иконки на тулбаре тоже крайне мелкие, но тут хотя бы только размера, а не форма.
4. А где локализация? ) Понятно что для программистов это вопрос совершенно не принципиальный. Но с учётом того, что даже мелкие бесплатные редакторы (типа Notepad++) имеют локазализацию (причём работающую по умолчанию), а во всех сравнимых конкурентах (Netbeans, Eclipse, Visual Studio) это уже давно работает, то несколько удивляет. Тем более, что уж для русской версии переводчиков точно не пришлось бы нанимать. )))
Кстати, замечу, что все вышеуказанные проблемы явно не связаны со спецификой C++. Интересно, а в других продуктах компании наблюдаются эти же проблемы или нет? Т.е. это предрелизные проблемы или вообще характерное для них? Я сам не в курсе, т.к. для нас у них раньше не было подходящих продуктов.
Переходим к основному. Первым делом нас конечно встречает редактор. Ну а точнее его настройки, т.к. я сразу полез в них. Ну что я могу сказать. Пожалуй это лучшее, что я видел среди всех IDE. Причём там нет какой-то одной уникальной киллер-фичи, а просто по совокупности разных продуманных мелочей редактор выглядит заметно удобнее всех своих конкурентов. Не буду расписывать тут подробности (авторы сами это легко сделают в рекламных проспектах, в отличие от подробного описания проблем), но можно сказать что тут ожидания полностью оправдались.
Однако подобный редактор — это ничто без анализатора кода (самой проблемой частью для C++). Здесь у нас к сожалению нет какого-то гениального прорыва (типа парсинга 100% компилируемого кода, что кстати вполне возможно с помощью того-же clang’а, но пока слишком медленно), но и провала нет. По охвату кода ситуация наверное как у лидеров, но при этом ещё и быстродействие чуть лучше. В целом получается как минимум на уровне, если не лучший результат. В принципе тоже безусловный позитив, хотя тут ожидания были несколько большими. Ну и надо отметить, что памяти оно отжирает больше того же Netbeans’a (Eclipse’а и VS+VA сейчас под рукой нет, чтобы сравнить), но думаю что для компьютера разработчика это правильный размен.
Ну а дальше я перешёл к изучению системы проектов и тут уже пошёл ужас — её просто не оказалось в IDE вообще. Ну точнее она вся перенесена в сторонний инструмент (чужую систему сборки cmake). Как я понимаю, авторы решили поддержать правильную точку зрения (которой некоторые IDE не соответствуют), что нормальный проект должен уметь собираться без всяких IDE (т.е. не должен быть завязан на настройки проекта из IDE). Я эту точку зрения полностью поддерживаю, но она совершенно не означает то, что сделали в CLion. Для этого достаточно всего лишь обеспечить удобную поддержку запуска произвольных сторонних систем сборки и всё! Отказываться от настроек проекта внутри IDE для этого не требуется. Т.е. авторы CLion вроде как пошли по правильному пути, но зашли по нему куда-то слишком далеко. В принципе такое решение может быть успешным, но только при одном принципиальном условие: если до первого релиза CLion будет поддерживать все известные системы сборки (например мы сейчас используем waf). Надеюсь автор данной архитектуры чётко понимает это? Ну и я что-то сомневаюсь что такое удастся, причём не столько из-за их количества (основных всего штук 15, хотя это тоже не мелкое число), сколько из-за сложности «парсинга» конфигов в некоторых случаях и большого различия в принципах. В целом мне данное решение видится провалом. Можно было сделать гораздо проще — сборку отдать профессиональным инструментам (реализовав удобный их запуск), а настройки проекта оставить только для нужных IDE опций (типа include каталогов для анализатора кода и т.п.). Кстати, я бы ещё может с трудом понял подобное, если бы в папке проекта кроме CMakeLists.txt не появлялось вообще ничего. Однако там появляется целая новая папка с кучей мусора (и почему-то именем «.idea», а не «.clion). Почему нельзя было разместить в ней нужные анализатору кода настройки, а не заниматься сексом с CMakeLists.txt для меня загадка.
Но ещё больше чудес открылось, когда я перешёл к сборке. И тут дело совсем не в её архитектуре. Ну да, cmake, не лучшая система сборки, но и далеко не худшая. Ну да, зашита намертво и поддерживается только она одна. Но это вроде как только пока и обещают изменить к релизу. Всё дело в том, как тут cmake используется! Оно зачем-то создаёт папки (да, не одну, а сразу 5: default, Release, Debug, RelWithDebInfo, MinSizeRel — зачем. ) для построения cmake’ом не в каталоге проекта, а где-то в домашнем каталоге пользователя (типа ~\.clion10\system\cmake\generated\7c448f19\7c448f19\)! Мне вот интересно, а «гений», придумавший это решение, вообще понимает, что:
— это может приводить к потери быстродействия (диски с проектами и домашним каталогом могут быть не просто с разной скоростью, а вообще расположены в разных точках планеты)
— это может являться существенной дырой в безопасности (к примеру у нас важные проекты живут на криптодисках, а домашние каталоги пользователей со всяким повседневным хламом естественно без всякой защиты)
— банально неудобно доставить оттуда exe в итоге.
Причём главное что я не понимаю смысла этого гениального решения — какой вообще может быть аргумент в пользу подобного извращения? Да, а в какой-нибудь IDE такое вообще встречалось? Я вот что-то не припомню.
Кстати, я попробовал прикрутить нормальное построение (другим инструментом и в каталоге проекта) через External Tools. Кривизна конечно, но для предрелиза сойдёт. Вроде как всё нормально заработало. Но тут выяснилось, что без корректного CMakeLists.txt не работает анализатор кода (а без него уже смысла в IDE нет). Ну хорошо, поставил корректный файл, но убрал шаг build (из run/debug) и не нажимал его руками. И что вы думаете? Оно всё равно тут же сгенерировало все эти 5 папок с полным содержимым (да, кстати, забыл добавить, что там ещё зачем-то лежат сгенерированные проекты для codeblock — а они то зачем. ) в домашнем каталоге. Даже не знаю что сказать на это всё.
Ну и напоследок об остальных компонентах, которые не произвели какого-то яркого (позитивного или негативного) впечатления.
Отладчик — ничего особо интересного, но нормально работает.
Всяческие интеграции — благодаря системе плагинов думаю что в будущем может быть идеально. Ну и даже уже сейчас, до релиза, имеется набор большинства важных вещей.
Если подвести итог с оценками, то по моим ощущениям это выглядело бы так:
— Интерфейс: 3-4.
— Редактор: 5.
— Анализатор кода: 4-5 (выше 4 только за счёт скорости).
— Проекты: 3.
— Сборка: 1.
— Отладчик: 4.
— Интеграции: 4-5 (4 сейчас, а 5 думаю быстро станет после релиза).
Для сравнения покажу такую же свою оценку Netbeans’a (на мой взгляд самого оптимального инструмента сейчас, хотя Eclipse не далеко от него):
— Интерфейс: 4-5.
— Редактор: 4.
— Анализатор кода: 4.
— Проекты: 4.
— Сборка: 4.
— Отладчик: 4.
— Интеграции: 5.
К сожалению для нас из всего этого следует, что переход на новую более удобную IDE похоже не состоится.
P.S. Тут вроде как на форуме присутствовали люди из JB. Надеюсь они передадут это отзыв по назначению. Я всё же его писал не ради самой критики, а с тайной надеждой на чудо в будущем. )))
Что это и зачем нужно
CMake — кроссплатформенная автоматизированная система сборки проектов. Непосредственно сборкой она не занимается, а только генерирует Makefile, который потом будет выполнен утилитой make.
CMake может проверять наличие необходимых библиотек и подключать их, собирать проекты под разными компиляторами и операционными системами. Т.е. у вас есть куча кода и файлик, содержащий информацию для cmake, и чтобы скомпилить это дело где-нибудь еще, вам нужно просто запустить там cmake, который сделает всё сам. Удобно, полезно, просто.
Краткое описание
Если нет желания/времени/сил читать весь туториал и Вы используете какой-нибудь QtCreator (или любая другая IDE, умеющая работать с cmake), то:
- Создайте в IDE проект под cmake
- Найдите в папке с проектом CMakeFiles.txt
- Пробегитесь глазами по туториалу, соотнося его с вашим CMakeFiles.txt
Про подключение библиотек рекомендуется все-таки прочитать целиком.
Старт
Предполагается, что найти и скачать сам cmake ты, %username%, в состоянии. //а если нет?
Предположим, у Вас есть исходничек «test.cpp» (// а если нет?)(А если нет, то CMake тебе трогать рано). Для начала нужно создать файлик для cmake, который обычно называют «CMakeLists.txt», и написать туда вот это:
add_executable(test test.cpp)
Теперь запускаем (из консоли) в этой папке команду «cmake CMakeLists.txt» (аргументом можно передавать не только файл, но и директорию, в которой он лежит, тогда cmake найдет его сам).
cmake будет использовать переданный (или найденный) файл проекта (тот самый CMakeLists.txt), и в текущей директории будет создавать проект. Проект — это много-много файлов и директорий (примечание: поэтому лучше запускать cmake из другой директории, чтобы можно было, например, быстро удалить все бинарники), из которых нас больше всего интересует Makefile.
Makefile — это файл, нужный для утилиты make. Именно она запускает компиляторы, линковщики и прочие радости. Запускаем make в каталоге сборки (т.е. там же, где Вы запускали cmake). В консоли вылезет примерно такой текст:
Scanning dependencies of target test [100%] Building CXX object CMakeFiles/test.dir/test.cpp.o Linking CXX executable test [100%] Built target test
А у Вас в папочке появится исполняемый файл «test». Запустите, убедитесь, что это действительно то, что ожидается от компиляции файла «test.cpp».
Подробное описание
Поразбираемся с различными возможностями cmake.
Указание необходимой версии cmake
cmake_minimum_required(VERSION 2.6)
Указывайте высокую минимальную версию CMake. Если используемая версия cmake меньше 2.6, он не захочет работать. Писать эту команду всегда — хороший стиль (cmake будет пыхтеть и обижаться, если вы не укажете версию, но собирать всё равно всё будет).
Название проекта
project(visualization)
Указывает, что этот cmake-файл является корневым для некоторого проекта. С проектами связаны определенные переменные и поведение cmake (читайте документацию).
Переменные
В cmake можно создавать текстовые переменные. Команда
set(VARIABLE The variable's value)
запишет в переменную «VARIABLE» значение «The variable’s value». Чтобы где-либо использовать значение этой переменной, нужно написать $.
Чтобы добавить к переменной некий текст, можно сделать так:
set(VARIABLE "$ new text")
Как видите, использовать значение можно и внутри кавычек. Переменные активно используются различными библиотеками — для установки флагов, параметров сборки/линковки и прочих вкусностей, об этом чуть-чуть попозже.
Пример коше’гного проекта со списком сорцов в отдельной переменной:
cmake_minimum_required(VERSION 2.6) set(SOURCES test.cpp lib1.cpp lib2.cpp) add_executable(test $)
Устанавливаем команды компилятору
add_definitions(-DSOME_IMPORTANT_DEFINITION)
Эта команда используется для установки дефайнов, которыe можно проверить в коде через, например, #ifdef SOME_IMPORTANT_DEFINITION.
set(CMAKE_CXX_FLAGS "$ -std=c++11 -Wall")
Эта команда добавит к флагам, используемым при сборке c++-кода, флаги -std=c++11 и -Wall.
Кто не знает: «-std=c++11» включает в gcc поддержку стандарта c++11, «-Wall» говорит gcc выводить все предупреждения (очень советую, помогает отловить много глупых багов и писать аккуратный код).
Если ваша версия GCC меньше, чем 4.7.0, вместо -std=c++11 нужно использовать -std=c++0x.
В GCC 4.8.0 появился флаг -std=c++1y, в котором начинают реализовывать фичи следующего стандарта.
Папка с хедерами
Допустим, Вы хотите, чтобы хедеры (файлики, подключаемые через #include) искались еще и в каталогах «headers/» и «more_headers/»:
include_directories("headers/" "more_headers/")
Надеюсь, и это понятно.
Самое важное — подключение библиотек
Научимся искать и подключать библиотеки при помощи cmake на примере Boost. Для начала установим переменные для буста:
set(Boost_USE_STATIC_LIBS OFF) set(Boost_USE_MULTITHREADED ON)
Первое — мы не хотим, чтобы буст подключался к нам статически (т.е. хотим динамическую линковку). Если ты, %username%, не знаешь, что это, пока просто забей и используй этот флаг так, как написано. Но в ближайшее время узнай, о чем речь. Второй флаг разрешает бусту внутри своих магических реализаций использовать треды для распараллеливания и прочих радостей.
Итак, мы установили флаги. Давайте найдем буст!
Допустим, нам нужны компоненты буста под названием chrono (библиотека для работы со временем) и filesystem (библиотека для работы с файловой системой):
find_package(Boost COMPONENTS chrono filesystem REQUIRED)
Win, будут искаться только нужные библиотеки, и их расположение будет записано в переменную Boost_LIBRARIES.
Опция «REQUIRED» говорит о том, что библиотека необходима проекту. Без нее cmake решит, что отсутствие данной библиотеки — не так уж и страшно, и будет собирать дальше.
Добавим директории с хедерами буста для поиска в них хедеров:
include_directories($)
Итак, осталось найденные библиотеки подключить к исполняемому файлу.
target_link_libraries(test $)
В качестве библиотек нужно указать пути к необходимым собранным библиотекам. cmake нашел указанные нами библиотеки и записал в переменную, чем мы и пользуемся.
Заметим, что эту команду нужно вызывать после того, как создан target сборки (через add_executable).
Пример хорошего CMakeLists.txt и где он будет лежать
Итак, полный пример использования всего этого. У нас есть некая директория (отныне считаем ее «/sources»), и в ней лежат исходники
/sources/lib1/main.cpp /sources/lib2/main.cpp /sources/main.cpp
В корне «/» лежит файл «/CMakeLists.txt»:
cmake_minimum_required(VERSION 2.8) project(cmake-example) set(Boost_USE_STATIC_LIBS OFF) set(Boost_USE_MULTITHREADED ON) find_package(Boost COMPONENTS chrono filesystem REQUIRED) set(CMAKE_CXX_FLAGS "$\$$ -std=c++11 -Wall") set(SRC_LIST lib1/main.cpp lib2/main.cpp main.cpp) add_executable($\$$ $\$$) target_link_libraries($\$$ $\$$)
Если Вам что-то в нём не понятно — перечитайте соответствующую информацию выше.
Создаем директорию «/build» (не «/sources/build»), переходим в нее, запускаем в ней «cmake ..». «..» — метка родительской директории. cmake возьмет из нее наш CMakeLists.txt и по нему создаст проект в папке «/build». Чтобы проект собрать, запускаем «make» в той же папке «/build».
Таким образом, в корне у нас есть:
- CMakeLists.txt
- директория с исходниками
- каталог сборки
Все разделено, автоматизировано и удобно.
Как создать библиотеку в поддиректории и слинковать ее с основной программой
Пусть в ./ лежит основной проект, а в ./subdir мы хотим сделать либу, а в ./build построить проект.
project(MegaLibrary) set(SOURCES lib.cpp) set(HEADERS lib.h) add_library(lib $\$$ $\$$) target_include_directories(lib PUBLIC $\$$)
project(MainProject) set(MAIN_PROJECT_SRC_LIST main) # Other stuff
add_executable(main $\$$) add_subdirectory(subdir) target_link_libraries(main lib)
Теперь можно в файлах основного проекта делать #include «lib.h» (см. документацию по target_include_directories).
В ./build запускаем «cmake .. && make» и получаем собранный проект.
Как использовать CMake в связке с QtCreator
Интеграция с cmake у QtCreator не очень тесная, тем не менее, работать с ним можно.
Создаем новый проект без использования Qt, выбираем «Проект на С++ с использованием CMake». Создастся дефолтный файл сборки, который просто добавляет все исходники в директории проекта и компилирует их в один бинарник.
Как добавить header в проект, чтобы его было видно в списке файлов
Если вы создали файл header.h в директорию проекта, просто строчку
add_executable($\$$ $\$$)
add_executable($\$$ $\$$ "header.h")
Отображение кириллицы в CLion
CLion по дефолту использует UTF-8 для хранения файлов с исходным кодом. Строка «Привет, Мир!» будет представлять собой последовательность (в файле с исходником):
D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82 2C 20 D0 9C D0 B8 D1 80 21 Как видите, на 12 символов исходной строки, получили 21 байт (т.к. кириллические символы занимают больше одного байта).
Компилятор GCC по умолчанию читает исходники в кодировке UTF8 , если не указать другую через ключ -finput-charset . Таким образом эта последовательность байтов в неизменном виде сохранится в исполняемый файл.
При запуске программы на исполнение, CLion использует стандартный cmd.exe , который по умолчанию скорей всего у вас работает в кодировке CP866 . В которой наша последовательность байтов будет отображена как:
╨Я╤А╨╕╨▓╨╡╤В, ╨Ь╨╕╤А! (что вы и видите в терминале CLion)
Что делать?
Вариант 1
Сменить кодировку файла на IBM866 (то же, что и CP866 ) (настройки — File Encodings) (сам файл перекодировать, если в нем уже был текст на русском). Теперь кириллица будет сохраняться в файле с исходным текстом в кодировке CP866 (один байт на символ), в том же виде попадать в исполняемый файл и нормально отображаться в консоли CLion. Разумеется, использовать CP866 в 19-м году, без особых на то оснований, некультурно. Кроме того придется ограничить себя символами из CP866 .
Вариант 2
Вставить в начало свой программы:
system("chcp 65001"); или (потребует #include ):
SetConsoleOutputCP(CP_UTF8); Консоль переключится в UTF-8 , все будет отображаться как надо. Но только при использовании низкоуровневых операций вывода типа puts(«Привет, Мир!»); . Если выводить через std::cout , то возможен вывод типа ��ривет, Мир! . Это связано с тем, что функция Windows API для вывода в консоль ожидает увидеть в каждом вызове законченную строку. И если оператор basic_ostream::operator
Предостережение
При использовании UTF-8 в своей программе, например при хранении в std::string , следует помнить, что операции над строками могут дать не очевидные результаты (т.к. один символ теперь может занимать от 1 до 4 байтов).
Кроме вывода, аналогичные проблемы ожидают и при вводе из std::cin . Таким образом, единственным прозрачным решением для Windows (даже десятки), пока остается использование латиницы.