Hello, Part of the design of the compile features concept is that it may be used to require compiler extensions. The extensions are enabled by default for GNU and Clang - that is, the option -std=gnu++98 is implied. Passing -std=c++98 disables the extensions, as do other language standard dialect variants such as -std=c++11 (as opposed to the option -std=gnu++11). Some other compilers implement similar options:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9812 Thus, the use of target_compile_features or the CXX_STANDARD target property can result in failure to compile if the extensions are used in the code. This is documented and can be fixed by the user either by setting CXX_EXTENSIONS, listing the feature requirement on the compiler extensions if known to CMake (none so far). This was the conclusion reached here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8115/focus=8193 1) This can be interpreted as inconsistent with how MSVC compile features are planned/designed to behave. For consistency, it could be justified to add /Za to MSVC command lines: http://msdn.microsoft.com/en-us/library/34h23df8.aspx http://msdn.microsoft.com/en-us/library/0k0w269d.aspx http://stackoverflow.com/questions/18771299/does-msvc-mishandle However, a counter-point is that it's unofficially considered harmful: http://clang-developers.42468.n3.nabble.com/MSVC-Za-considered-harmful-td4024306.html Choice quotes: 1) It's just that /Za is flaky, and it's rarely used which means that even less code exercises it. 2) The common problem is that standard library headers shipping with the compile *should* have access to the extensions. The move emulation referenced by Benjamin Kramer was removed, as the Clang developers require a more recent MSVC version already: https://github.com/llvm-mirror/clang/commit/3fe198bf0d61 and the use of the option was removed too: https://github.com/llvm-mirror/clang/commit/a08e7bc74b56 2) My code can be portable while not disabling extensions to allow third- party headers to take advantage of them. Regarding quote (2), I find a few uses of __STRICT_ANSI__ in my libstdc++ headers, but none in my libcxx headers. It makes sense to me that std library releases, which are tied to the compiler release, can take advantage of compiler extensions if available without affecting the portability of my code. The same is true for headers of third-party libraries I use. At least Boost::Math is affected by whether __STRICT_ANSI__ is defined, relating to int128 use. 3) Disabling extensions is not well-tested and can cause bugs not obviously caused by disabling them Quote (1) above relates to this. Here is a similar quote for GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278 [the issue] appears also for -std=c++98 vs -std=gnu++98, but often it's not noticed because people don't use -std=c++98 very often. The fact that -std=c++98 (and -std=c++11 to some extent) is not often used means that bugs exposed might not obviously be caused by it. This is also a point made here, which I think makes some sense: https://lists.launchpad.net/kicad-developers/msg11843.html From the point of view of the CMake interface, requiring a feature by using target_compile_features is a more obvious change than the implicit disabling of extensions. 4) Platform support headers may depend on compiler extensions This is also a cause of surprise, particularly if the platform affected is not one primarily used by the developers. For example, off_t not defined in mingw with std=c99 http://sourceforge.net/p/mingw/bugs/2046/ http://sourceforge.net/p/mingw/mingw-org-wsl/ci/088538f717bbafc5079940f3df298172a38ec4c1/ http://ehc.ac/p/mingw/bugs/2200/ https://github.com/mozilla/rust/issues/10893 https://github.com/llvm-mirror/clang/commit/a82a9c0cfc https://github.com/llvm-mirror/llvm/commit/5de64fcb5e http://llvm.org/bugs/show_bug.cgi?id=18847 https://github.com/llvm-mirror/llvm/commit/3f06e3f55fb I could not reproduce the problems with the MinGW I have, and I asked Rafael EspĂndola if he had any more information about what version of MinGW would be needed etc, but he had no more information. I don't know that it is still a problem, but I suspect it is. 5) The XL compiler has no group compile option for 'non-extended' C++11 http://pic.dhe.ibm.com/infocenter/lnxpcomp/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.linux.doc%2Flanguage_ref%2Fcpp0x_exts.html http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9812 So, for that compiler, the only option is the equivalent of -std=gnu++11, which is not consistent with the GNU/Clang behavior. For the above reasons of consistency, having an interface in CMake which does not unnecessarily change default behavior of compilers, 'least surprise', allowing optimal content in third-party headers, and having an interface in CMake which does not implicitly increase exposure to bugs, I recommend we change C{,XX}_EXTENSIONS to 'on-by-default'. The user may still set it to FALSE explicitly in order to use a possible non-extended compile option where available. Specifically, if set to FALSE, that would mean CMake would use -std=c++11 instead of -std=gnu++11 with GNU or Clang. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers