The 199711L stands for Year=1997, Month = 11 (i.e., November of 1997) -- the date when the committee approved the standard that the rest of the ISO approved in early 1998.
For the 2003 standard, there were few enough changes that the committee (apparently) decided to leave that value unchanged.
For the 2011 standard, it's required to be defined as 201103L, (again, year=2011, month = 03) again meaning that the committee approved the standard as finalized in March of 2011.
For the 2014 standard, it's required to be defined as 201402L, interpreted the same way as above (February 2014).
For the 2017 standard, it's required to be defined as 201703L (March 2017).
For the 2020 standard, the value has been updated to 202002L (February 2020).
For the 2023 standard, the value has been updated to 202302L (February 2023).
Before the original standard was approved, quite a few compilers normally defined it to 0 (or just an empty definition like #define __cplusplus) to signify "not-conforming". When asked for their strictest conformance, many defined it to 1.
I almost forgot to mention, but one more tidbit about ancient compilers: a few of the earliest versions of cfront (and probably a few others copying it) defined c_plusplus instead of __cplusplus. I don't recall it's being defined to any meaningful value though.
Best Answer
cppreference has information on the standard values of the
__cplusplusmacro in the section "Predefined macros." Currently the standard values are:199711L(C++98 or C++03)201103L(C++11)201402L(C++14)201703L(C++17)202002L(C++20)202302L(C++23)The macro's value for any given version isn't firmly established until the final standard is published. Therefore, as of June 2019, there was no way to know what the macro value for C++2a would be (and as of Feb 2021 there's no way to know what the value will be for C++2b).
Library vendors typically gate their "C++2a" features on
#if __cplusplus > 201703L, and their "C++2b" features on__cplusplus > 202002L, and so on.Compiler vendors with a "C++2a" mode simply picked any arbitrary value for
__cplusplusthat made the library vendors' checks happy:GCC (8.x thru 10.x)
-std=c++2amode uses__cplusplus == 201709L.Clang (5.x thru 9.x)
-std=c++2amode uses__cplusplus == 201707L.Microsoft Visual Studio (19.20 thru 19.28)
/std:c++latestmode uses__cplusplus == 201705Lif and only if you pass/Zc:__cplusplus! Otherwise it uses199711L. So watch out for that!How have transitions historically been handled?
Clang 4.0.1
-std=c++1zset__cplusplus == 201406L. Clang 5.0.0 introduced-std=c++17and-std=c++2a, made-std=c++1za synonym for-std=c++17, and bumped the macro (no matter which of17/1zyou used) to the standard value201703L. Clang 10.0 introduced-std=c++20, made-std=c++2aa synonym for-std=c++20, and bumped the macro to the standard value202002L. As of Feb 2021, Clang has no formal "C++2b" mode.GCC 5.1 introduced
-std=c++1zand-std=c++17as synonyms out of the gate, setting__cplusplus == 201500L. GCC 7.1 bumped the value (no matter which spelling you used) to the standard value of201703L. GCC 8.1 introduced-std=c++2awith__cplusplus == 201709L. GCC 10.1 introduced-std=c++20as a synonym for-std=c++2a(but left the macro at201709L). As of Feb 2021, GCC trunk has introduced-std=c++2bwith__cplusplus == 202100L.Oddly, according to Godbolt Compiler Explorer, MSVC bumped the macro for
-std:c++latestmode from201704Lto201705Lsometime between MSVC 19.16 and 19.20. As of Feb 2021, as far as I know, MSVC has no formal "C++20" mode.