Как узнать разрядность компилятора visual studio
Обновлено: 05.07.2024
Мне нужно пропустить что-то действительно очевидное, но по какой-то причине версия командной строки компилятора Microsoft С++ (cl.exe) не поддерживает отчетность только своей версии при запуске. Нам нужно это, чтобы написать make файлы, которые проверяют версию компилятора, которую установил пользователь нашего инструмента (они получают make файлы с кодом, который они должны компилировать локально, поэтому мы не контролируем их версию компилятора).
В gcc вы просто передадите опцию -v или --version, чтобы получить красивую строку с версией.
Я прочитал интерактивную справку MSDN docs и компилятора, и я не могу найти переключатель, чтобы просто распечатать версию компилятора. Раздражающе, вы всегда получаете версию, когда компилятор запускается. но вы, похоже, не можете запустить компилятор, чтобы получить версию.
Поиск поставщика/версии компилятора с использованием qmake показался похожим, но касается только простого случая gcc.
Я пробую это с VС++ Express 2005, если это имеет значение. Я надеялся, что этого не произойдет, так как обнаружение версии компилятора лучше всего сделать не зависящим от компилятора способом:
- Запуск cl.exe без каких-либо аргументов печатает свою версию и некоторую помощь текст.
- Это выглядит как наиболее портативный способ получить версию, версии vc.
- Затем вы должны проанализировать многострочный вывод, но не слишком сложно.
- Мы сделали это в конец, и он работает.
ОТВЕТЫ
Ответ 1
d:\Program Files\Microsoft Visual Studio 9.0\VC > cl
Microsoft (R) 32-разрядная версия оптимизатора для C/С++ версии 15.00.30729.01 для 80x86
В 2005 году SP 1 (добавлены классы безопасного стандарта С++):
C:\Program Files\Microsoft Visual Studio 8\VC > cl
Microsoft (R) 32-разрядный оптимизатор компилятора C/С++ версии 14.00.50727.762 для 80x86
C:\Program Files\Microsoft Visual Studio 8\VC > cl
Microsoft (R) 32-разрядная оптимизация компилятора C/С++ версии 14.00.50727.42 для 80x86
Microsoft (R) 32-разрядный оптимизатор компилятора C/С++ версии 13.10.6030 для 80x86
ИЗМЕНИТЬ
В течение 2010 года он будет по линии:
Microsoft (R) 32-разрядная оптимизация компилятора C/С++ версии 16.XX.YYYYY.ZZ для 80x86
или в зависимости от целевой платформы
Microsoft (R) C/С++ Оптимизация компилятора версии 16.XX.YYYYY.ZZ для x64
Microsoft (R) C/С++ Оптимизация компилятора Версия 17.XX.YYYYY.ZZ для $$$
где $$$ - целевая платформа (например, x86, x64, ARM) и XX, YYYYY и ZZ - это небольшие номера версий.
Microsoft (R) C/С++ Оптимизация компилятора Версия 18.XX.YYYYY.ZZ для $$$
где $$$ - целевая платформа (например, x86, x64, ARM) и XX, YYYYY и ZZ - это небольшие номера версий.
В течение 2015 года:
Microsoft (R) C/С++ Оптимизация компилятора версии 19.XX.YYYYY для $$$
где $$$ - целевая платформа (например, x86, x64, ARM), а XX и YYYYY - младшие номера версий.
Ответ 2
У меня была такая же проблема сегодня. Мне нужно было установить флаг в makefile makefile, если версия компилятора cl равна 15. Вот взлом, который я придумал:
Вышеупомянутая идея может быть использована для написания командного файла Windows, который проверяет, является ли версия компилятора cl <= заданным номером. Вот код cl_version_LE.bat :
Теперь, если вы хотите установить флаг в файле makefile nmake, если версия cl <= 15, вы можете использовать:
Ответ 3
и раздел "Краткое справочное руководство по номерам версий Visual С++".
Ответ 4
Просто запустите его без параметров.
Ответ 5
Собственно, в любое время, когда я даю cl аргумент, он выводит номер версии в первой строке.
Вы можете просто передать ему аргумент мусора, а затем проанализировать первую строку вывода, содержащую номер проверки.
Вопрос в следующем. Существует ли какой-нибудь кроссплатформенный метод определения разрядности платформы на этапе препроцессинга?
Гоголь показывает только:
и какое-то дикое обсуждение:
Но нам нужно другое - способ, работающий и в GCC Linux, и в винде, и с разными компиляторами.
У кого-нибудь готовое условие не завалялось?
где-то так наверное
Вот потому что ищещь по виндовым терминам, потому и находишь только win64. Эти архитектуры называются x86, amd64/x86-64.
Так наверно или точно?
> Так наверно или точно?
первое для gcc, второе для msvc, надо что-то еще - ищи сам
неужели так сложно (U)LONG_MIN/MAX проверить?
а где вы псдений раз видели 32-хбитную платформу?
толсто, у меня все домашние системы 32-битные.
Просто в другом месте нахожу:
верить не надо, есть документация, для gcc:
там множество решений
Спасибо, на этом и остановлюсь.
я имею в виду 32-хбитный процессор. Все процессоры, выпущенные за последние года 3 имеют 64-битную архитектуру. Давайте все таки не считать пользователей за дуарков, которые будут ставить 32-хбитную ОС на 64-хбитный процессор.
А корректно ли определять через размер size_t?
> А корректно ли определять через размер size_t?
технически - да, но в стандарте, насколько я знаю, размер size_t не указан, т.е. может зависеть от реализации
> Давайте все таки не считать пользователей за дуарков, которые будут ставить 32-хбитную ОС на 64-хбитный процессор.
Но такие есть, и им пофигу на разрядность.
да? Жаль. Я всех своих знакомых на работе пересадил на x86_64 OS (Ubuntu в данном случае)
Пересади меня! А то мне с моим старым ноутом у которого всего 1гб памяти и процом core duo который не держит 64бита как-то ссыкотно переходить.
Вот лол так лол.
> Я всех своих знакомых на работе пересадил на x86_64 OS (Ubuntu в данном случае)
мой п4, которому лет 6 - написано, что умеет amd64 - на деле - нет(
>верить не надо, есть документация
Everybody lies. Это только на IA-64 определено (Itanium).
ясно, да - по названию можно было догадаться, поверил описанию
Но зачем? Если памяти меньше 4G, Вы ничего не выиграете, а наоборот, т.к. 64х-битные приложения требуют больше памяти.
Это действительно нужно? Обычно лучше использовать типы известного размера, например int64_t, u_int32_t и т.п. (см. /usr/include/sys/types.h).
> например int64_t
ISO/IEC 9899:1999 → 7.18.1.1 → 3) These types are optional.
Хуже того: их нет даже в MSVC, поэтому там придётся использовать __int64. Он был приведён для примера.
> Хуже того: их нет даже в MSVC
> их нет даже в MSVC
> даже в MSVC
/me подавился пивом…
на винде оно sizeof(long) не зависит от архитектуры x86/x86-64
Я бы распарсил в cmake uname. Или из /proc можно попытаться информацию извлечь. А вот как это сделать в мастдае - понятия не имею.
Где? В своей коробочной русской MS Visual Studio 2008 Professional не нашёл.
Осторожнее надо. IMO сей компилятор - второй по распространённости, если не первый.
Про кроccкомпиляцию мусье не слышал?
Зато для линукса это самое простое решение. А как там в мастдае - понятия не имею. Но для cmake можно сделать проверку на ОС и, в зависимости от нее, вызывать тот или иной велосипед.
кроccкомпиляция подразумевает сборку и под линукс, но другой архитектуры, как самый простой вариант - 32 бита из под 64-битной системы
У ТСа такой задачи не было. Так что не запутывайте.
И, кстати, ЕМНИП, без ВМ не получится (я уже как-то пытался себе дженту 64-битную закомпилять, не пользуясь ВМ - ничего не вышло).
> И, кстати, ЕМНИП, без ВМ не получится
В мане написано, что это для сборки вроде 32бита из-под 64-х. Но что-то у меня, несмотря на всякие ключики в make, 64-битное ядро компилироваться 32-битным gcc не стало.
> Но что-то у меня, несмотря на всякие ключики в make, 64-битное ядро компилироваться 32-битным gcc не стало.
КО говорит, что ты просто не умеешь
Зато для линукса это самое простое решение.
Заканчивай уже пить пиво, оно у вас там с веществами, однозначно.
Молодцы, оперативно работают. Но закладываться на последнюю версию компилятора неправильно IMO.
Сделать проверку компилятора проще на порядки. И безо всяких cmake, а прямо в коде. Для Windows есть набор define'ов, которые устанавливают все компиляторы, а в Linux с вероятностью 99% используется GCC. Способа, который работал бы везде и всегда, AFAIK нет. Даже если бы он был в стандартах, всегда найдётся кто-нибудь, кто им соответствует не полностью.
> Молодцы, оперативно работают.
>Существует ли какой-нибудь кроссплатформенный метод определения разрядности платформы на этапе препроцессинга?
Как с огромным количеством различных версий языка C++ (C++98, C++03, C++11, C++14, C++17, C++20) компилятор понимает, какую из них ему следует использовать? Как правило, компилятор выбирает стандарт языка по умолчанию (часто не самый последний языковой стандарт). Если вы хотите использовать другой стандарт, то вам придется внести изменения в настройки вашей IDE/компилятора. Эти настройки применяются только к текущему проекту. При создании нового проекта вам придется всё делать заново.
Кодовые имена для версий языка С++
Обратите внимание на то, что каждый языковый стандарт имеет название, указывающее на год его принятия/утверждения (например, C++17 был принят/утвержден в 2017 году).
Однако, когда согласовывается новый языковой стандарт, неясно, в каком году удастся его принять, поэтому действующим языковым стандартам присваиваются кодовые имена, которые затем заменяются фактическими именами при доработке стандарта. Например, C++11 назывался c++1x , пока над ним вели работу. Вы можете по-прежнему видеть на просторах Интернета подобные кодовые имена (особенно, когда речь заходит о будущей версии языкового стандарта, у которого еще нет окончательного названия).
Вот сопоставление кодовых имен версий С++ с их окончательными названиями:
Например, если вы видите c++1z , то знайте, что речь идет о стандарте C++17.
Установка стандарта языка С++ в Visual Studio
На момент написания данной статьи, Visual Studio 2019 по умолчанию использует возможности C++14, что не позволяет использовать более новые фичи, представленные в C++17 и в C++20.
Чтобы использовать новый функционал, вам необходимо подключить новый языковой стандарт. К сожалению, сейчас нет способа сделать это глобально — вы должны делать это к каждому проекту индивидуально.
Чтобы использовать новый языковый стандарт в Visual Studio, откройте ваш проект, затем щелкните правой кнопкой мышки по названию вашего проекта в меню "Обозреватель решений" > "Свойства" :
В диалоговом окне вашего проекта убедитесь, что в пункте "Конфигурация" установлено значение "Все конфигурации" . Затем перейдите на вкладку "C/C++" > "Язык" и в пункте "Стандарт языка С++" выберите ту версию языка С++, которую хотели бы использовать:
На момент написания данной статьи, я рекомендую выбрать "Стандарт ISO C++17 (/std:c++17)" , который является последним стабильным стандартом.
Если вы хотите поэкспериментировать с возможностями грядущего стандарта языка C++ — C++20, то вы можете выбрать пункт "Предварительная версия . (/std:c++latest)" . Просто помните, что его поддержка может иметь баги.
Установка стандарта языка C++ в Code::Blocks
Code::Blocks по умолчанию может использовать стандарт C++11. Хорошей новостью является то, что Code::Blocks позволяет устанавливать ваш стандарт языка С++ глобально, поэтому вы можете установить его один раз и сразу на все проекты (а не для каждого проекта в индивидуальном порядке). Для этого перейдите в меню "Settings" > "Compiler" :
Затем на вкладке "Compiler flags" найдите следующие пункты меню:
Отметьте тот пункт, у которого число обозначает ближайший (к текущему) год утверждения стабильной версии и нажмите "ОК" (на вышеприведенном скриншоте этим пунктом является "Have g++ follow the C++17 ISO C++ language standard [-std=c++17]" ).
Примечание: Если вы не нашли в ваших настройках опцию с C++17, то вам следует обновить вашу версию Code::Blocks.
Установка стандарта языка С++ в GCC/G++
В GCC/G++ вы можете прописать соответствующие флаги -std=c++11 , -std=c++14 , -std=c++17 или -std=c++2a , чтобы подключить функционал C++11/14/17/20, соответственно.
Тестирование вашего компилятора
После подключения версии C++17 или выше, вы можете провести тест, который позволит понять, всё ли верно сделано и действительно ли подключена новая версия языка С++. Следующая программа в С++17 должна выполниться без каких-либо предупреждений или ошибок:
Мне неясно, как компилятор автоматически узнает, что нужно для 64-битной компиляции, когда это необходимо. Как он узнает, когда он может уверенно нацеливаться на 32-битную версию?
Мне в основном интересно, как компилятор знает, на какую архитектуру ориентироваться при компиляции. Анализирует ли он код и принимает ли решение на основе того, что находит?
Ах, спасибо. Не видел этого раньше. Мне все еще интересно, как компилятор автоматически узнает, на какую архитектуру нацеливаться. Любые идеи?- Если процесс выполняется в 32-разрядной системе Windows, он выполняется как 32-разрядный процесс. IL скомпилирован в машинный код x86.
- Если процесс выполняется в 64-разрядной системе Windows, он выполняется как 32-разрядный процесс. IL скомпилирован в машинный код x86.
- Если процесс выполняется в системе ARM Windows, он выполняется как 32-разрядный процесс. IL скомпилирован в машинный код ARM.
Вот простой ответ:
Причина в том, что если вы не хотите использовать больше памяти с 64-битными приложениями. Это означает, что если ваше приложение AnyCPU , вы хотите работать как 32-битный.
Чтобы добавить больше, настройка в Visual Studio нацелена на конкретный CLR:
Visual Studio устанавливает 32-разрядную версию CLR на компьютере с архитектурой x86, а также 32-разрядную версию и соответствующую 64-разрядную версию CLR на 64-разрядном компьютере с Windows. (Поскольку Visual Studio представляет собой 32-разрядное приложение, при установке в 64-разрядной системе оно работает под управлением WOW64.)
Читайте также: