Указание диалекта под виндой

диалект задаётся в цмэйке следующим образом:

А надо вот так:

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED TRUE)
set(CMAKE_CXX_EXTENSIONS FALSE)

Ну или set_property(TARGET target PROPERTY CXX_STANDARD 20)

Чёт не помогает, я влепил в главном цмейке: 3 сет строки, ну и set_property() для таргета с опициями, сборка также падает.

Влепил до определения цели, или после?

сет строки вначале файла, до определения целей.

В корневом CMakeLists.txt после командыproject()` (можно и до, но я обычно ставлю после)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

set_property() для таргета с опициями

Не нужно. CMAKE_CXX_STANDARD - и есть значение по умолчанию для property.

Чёт не помогает

Очистку каталога сборки делал?

Какой компилятор и версия?

Какой компилятор и версия?

MSVC из последней студии, хз как там версию смотреть.

Но тут дело похоже в другом, какие-то странные виндоспецифичные проблемы.

This macro has stubbornly remained at the value “199711L”, indicating (erroneously!) that the compiler conformed to the C++98 Standard. … You need to compile with the /Zc:__cplusplus switch to see the updated value of the __cplusplus macro. We tried updating the macro by default and discovered that a lot of code doesn’t compile correctly when we change the value of __cplusplus.

В общем надо как-то попросить цмейк передать необходимые флаги при необходимости в MSVC. Если он не может делать это сам и мне самому нужно расставлять ИФЫ и вникать во весь этот виндовый идиотизм, то я вряд ли это будут делать. Значения макроса стандартизированы, не буду я здесь костыли городить.

Не знаю как C++20, но флаги для C++17 CMake точно умеет передавать в MSVC.

Версия MSVC

C:\Program Files (x86)\Microsoft Visual Studio\Installer>vswhere.exe

Очистка каталога сборки не помогает?

Не. Тут ведь стандарт и фичи я задаю, они доступны и работают, но у мелкомягких какие-то свои тараканы, и у них макрос __cplusplus не отражает текущий диалект, говорит, что цпп98, что, очевидно, идиотизм. Для исправления этого нужно дополнительно передать /Zc:__cplusplus флаг, цмейк дефолтно этого не делает. Сделать самому руками в общем-то и несложно, но моё мнение, не я должен исправлять MSVC баги и плодить костыли в своих скриптах. Ещё здесь обсуждалось https://gitlab.kitware.com/cmake/cmake/-/issues/18837

Спасибо за участие.

У тебя уйдут годы, если не десятилетия, пока прикостылят в CMake и весь мир обновится. и в это время ты всё равно будешь использовать воркэраунд, так что просто добавь дополнительный флаг в target_compile_options() и забудь.

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

#if !defined(__cplusplus) || __cplusplus < 201703L
#error "Requires complete C++17 support"
#endif

а это у тебя в коде проекта?

Это внешняя ho либа. Имхо, вообще ненужная конструкция, можно вовсе выкинуть. Там автор не написал CMakeLists, тупо воткнул такую проверку. В общем все вокруг со своими тараканами.

Имхо, вообще ненужная конструкция, можно вовсе выкинуть.

Не норкоман ли ты часом? А если автор использует фичи, доступные только с C++17 ?

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

Вообще интересный случай. Я очевидно с таким не сталкивался. Помечу на будущее решение по твоей ссылке

https://gitlab.kitware.com/cmake/cmake/-/issues/18837

# /Zc:__cplusplus is required to make __cplusplus accurate
# /Zc:__cplusplus is available starting with Visual Studio 2017 version 15.7
# (according to https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus)
# That version is equivalent to _MSC_VER==1914
# (according to https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=vs-2019)
# CMake's ${MSVC_VERSION} is equivalent to _MSC_VER
# (according to https://cmake.org/cmake/help/latest/variable/MSVC_VERSION.html#variable:MSVC_VERSION)
if ((MSVC) AND (MSVC_VERSION GREATER_EQUAL 1914))
	target_compile_options(MainApp PUBLIC "/Zc:__cplusplus")
endif()

Можно зафигачить ему пул реквест с фиксом.

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

Сломанный __cplusplus - это на самом деле очень мелкая трабла при портировании в направлении Linux->Windows. Дальше ещё придётся расчехлять /permissive- и /bigobj, и патчить и переписывать все падающие места, которые на (GNU/)Linux как-то по совпадению работали.

Если он как порядочный кладёт рядом со своей поделкой CMakeLists.txt

И ты на это надеешься - то все вопросы к CMake’у.

Сейчас каждый должен писать сборочный скрипт за него

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

в написании скрипта сборки и выкидывании лишнего мусора из кода.

Я был прав, ты - норкоман. Только конченный даун будет заменять проверки времени компиляции встроенными средствами платформы разработки какими-то «сборочными скриптами» от васяна для васянских поделий (типа CMake’а).

которые на (GNU/)Linux как-то по совпадению работали

Ага, конечно, как в Винде не работает - так мелкая трабла, как в Linux работает, так по совпадению.

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

Епать, ты демагог. Если бы все так забивали на настройку сборки, то весело было бы собирать проекты размера Qt самостоятельно.

Только конченный даун будет заменять проверки времени компиляции встроенными средствами платформы разработки

В идеальном розовом мире то конечно да. Но вот в реальном приходится делать так, чтобы работало здесь и сейчас, а не в теории, когда микрософтОВЦЫ или CMake-товцы запилят соответствующую фичу.

Если бы все так забивали на настройку сборки,

А все так и забивают. Давай-ка собери сходу первый попавшийся крестопроект с гитхтаба под какой-нибудь обскурный MIPS32 или даже просто IA-64.

В идеальном розовом мире то конечно да.

В любом мире проверки на версию компилятора в исходниках программы предпочтительнее любой формы костылей.

вот в реальном приходится делать так, чтобы работало здесь и сейчас,

Ну и делай себе на здоровье - документация есть, аппаратура есть. Каким образом проверки в исходниках тебе мешают?

А все так и забивают. Давай-ка собери сходу первый попавшийся крестопроект с гитхтаба под какой-нибудь обскурный MIPS32 или даже просто IA-64.

Первый попавшийся - не аргумент. Нужно брать более менее популярные. Тоже и с компиляторами.

В любом мире проверки на версию компилятора в исходниках программы предпочтительнее любой формы костылей.

Дело не в том, что предпочтительнее, дело в том, что НЕ СДЕЛАНО В CMakeLists.txt. Хотя для самых используемых компиляторов можно было бы и запилить.

Ну и делай себе на здоровье - документация есть, аппаратура есть. Каким образом проверки в исходниках тебе мешают?

Мне ничем. Читай выше.

Ваши программы - не программы!

Ну, извини, другой базы исходных кодов у меня для тебя нет.

Нужно брать более менее популярные.

Это мы прикрыли один глаз от реальности.

Тоже и с компиляторами.

А это мы прикрыли второй.

Дело не в том, что предпочтительнее,

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

НЕ СДЕЛАНО В CMakeLists.txt. Хотя для самых используемых компиляторов можно было бы

А можно и не. А можно и вообще без CMakeLists.txt. Вон, сколько openssl без него живёт - и ничего.

прикрыли один глаз от реальности

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

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

Про правильность выкидывать/не выкидывать ты спорь с кем-нибудь другим. Это меня не очень волнует.

А можно и не. А можно и вообще без CMakeLists.txt. Вон, сколько openssl без него живёт - и ничего.

Ну тут уж как кому. Но если взялся пилить сборку на CMake - то может довести до того, чтобы пользователям не нужно было самим ничего допиливать?

Я был прав, ты - норкоман. Только конченный даун будет заменять проверки времени компиляции встроенными средствами платформы разработки какими-то «сборочными скриптами» от васяна для васянских поделий (типа CMake’а).

Ты пишешь что-то странное. Ну заюзал я концепты на цпп11, например, сборка упадёт и компиль сообщит «концепты доступны с цпп20», короче сомнительна необходимость это вообще провеять.

Про васянские подекли, ну по-моему это относится к какому-то дерьму, способ сборки/установки/линковки которого автора не волнует вовсе, он «проверки» вставил. Если тебя тянет на какую-то build-экзотику, то уж установку с pkgconf файлом ты сделать обязан.

А по моему игнорировать распределение проектов

То есть программисты должны писать код исходя из частотности использования, а компиляторы на основании же частотности эти проекты собирать?

Но если взялся пилить сборку на CMake - то может довести до того, чтобы пользователям не нужно было самим ничего допиливать?

Зачем? CMake делается в 99% случаев для сборки на локалхосте. Ты ведь любишь частотности использования, забыл штоле?

Ну заюзал я концепты на цпп11, например, сборка упадёт и компиль сообщит «концепты доступны с цпп20», короче сомнительна необходимость

2K22, программизды на крестах, которых мы заслужили.

то уж установку с pkgconf файлом ты сделать обязан

Кому обязан? Где подписанный контракт?

То есть программисты должны писать код исходя из частотности использования, а компиляторы на основании же частотности эти проекты собирать?

Ты логику превращаешь в винегрет. Вот мое утверждение:

Популярные проекты в массе своей (хотя и не всегда) не забивают на настройку сборки. Что ты там себе напридумывал - сам разбирайся.

Зачем? CMake делается в 99% случаев для сборки на локалхосте. Ты ведь любишь частотности использования, забыл штоле?

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

А вообще думай как хочешь, мне надоел этот спор.

Нет, не надо «вот так».

Устанавливать глобальные свойства – плохо, ТС правильно делает, устанавливая только таргетоспецифичные свойства. Использовать target_compile_features – правильно.

Ошибка у ТС, насколько я понимаю, из-за того, что MSVC не выставляет __cplusplus в актуальное значение. Для исправления этой ошибки следует передавать специальный флаг, см. https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170

Кому обязан? Где подписанный контракт?

Ну как знаешь, одним васяном больше, одним меньше …

Ты логику превращаешь в винегрет

Так это твоя логика. Где я виноват, что она у тебя - винигрет?

Опять-таки ты пытаешься натягивать логику одной ситуации на все вокруг.

Да нет же - я применяю твою логику к твоему же сценарию.

Если мы решили, что программисты на С/С++ могут забить на версии компилятора и редкие архитектуры в коде на С/С++, то с чего это они должны об этом суетится в каком-то сборочном скрипте наркоманской поделки с синтаксисом, придуманным больным мененгитом, и большим числом тикетов в багтрекере, чем строк в проекте?

Устанавливать глобальные свойства – плохо, ТС правильно делает, устанавливая только таргетоспецифичные свойства. Использовать target_compile_features – правильно.

Спорно. У тебя были ситуации использования в одном проекте разных версий стандарта?

Ошибка у ТС, насколько я понимаю, из-за того, что MSVC не выставляет __cplusplus в актуальное значение. Для исправления этой ошибки следует передавать специальный флаг, см. https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170

Там выше решение уже есть, взятое отсюда https://gitlab.kitware.com/cmake/cmake/-/issues/18837

Спорно. У тебя были ситуации использования в одном проекте разных версий стандарта?

Да.

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

А можно подробнее про твой кейс такого решения?

Очень просто: подъем версии в части компонентов согласовали, в части – нет. Согласование – процесс небыстрый, а фичи хочется здесь и сейчас.

Блин, ну тут как-бы не совсем технически обусловлено, а скорее бюрократически.

По поводу глобальности уже ответили, со своей стороны лишь укажу, что ТС предпочитает возню с опциями компилятора вместо выставления свойства цели. Да, с этим оказался баг, но в общем случае вся прелесть cmake как раз в возможности избавиться от этой возни в пользу универсального решения

/permissive- по умолчанию для С++20.

Но вот в реальном приходится делать так, чтобы работало здесь и сейчас, а не в теории, когда микрософтОВЦЫ или CMake-товцы запилят соответствующую фичу.

Про что речь? Все https://en.cppreference.com/w/cpp/feature_test поддерживаются в Visual C++.

Правильный вариант тестировать конкретную фичу, а не стандарт, так как часто в определенной версии компилятора реализована только часть фич очередного стандарта…

Ну или использовать такое сравнение

 __cplusplus >= 201703L || _MSCV_LANG >= 201703L

Тогда можно без флага… Очевидно либа не тестировалась на Visual C++…

Вообще есть такая заметка: https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/

К сожалению множество стороннего кода сломается если Visual C++ выставит корректное значение __cplusplus по умолчанию :(

(Часть проектов определяют что компилятор это Visual C++ по тому что __cplusplus равен 199711L )

Про что речь?

Указание диалекта под виндой (комментарий)

Правильный вариант тестировать конкретную фичу, а не стандарт, так как часто в определенной версии компилятора реализована только часть фич очередного стандарта…

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