How do I check for presence of individual C++0x/C++11 language features? I know Clang has a nice system for this. What about GCC, Visual Studio or Boost? I guess one way to do it is to detect the compiler version and relate that to the features introduced in that version. But that is cumbersome. Has someone already done that?
boost config comes with a script to check for some but not all C++11 features.
It generates a config-file with macros for each feature.
Your build-tool may be able to help with this.
CMake has the try_compile command which allows you to test whether a code sample will compile and set a variable based on the result of compilation.
At the moment I've just been using the more commonly supported features such as auto typing.
You can often use Boost to replace the missing library features, and this may be the best option for a few year while compilers and libraries are updated and bugs fixed.
The C++11 feature compatibility list for GCC is here: http://gcc.gnu.org/projects/cxx0x.html
Note the warning:
Important: GCC's support for C++11 is still experimental. Some features were implemented based on early proposals, and no attempt will be made to maintain backward compatibility when they are updated to match the final C++11 standard.
Related
I have a c++14 project that currently targets gcc 7.2, and I am looking to backport code from a project that targets c++17. This project makes extensive use of if constexpr. gcc 7.2 supports if constexpr with the --std=c++1z flag, however it brings along all the other (at the time) experimental C++17 features.
Is there a way to enable only specific language features, in this case if constexpr, in gcc 7.2?
No it is not possible. It's all or nothing.
There is some limited level of control over language dialect in g++
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
If these dialects are used it can raise a warning and you can turn this warning into an error.
Another way could be to create plugins for clang-tidy or clang-query to check your C++ code base do not use any construct you don't want, but it becomes a rather large work to achieve the intended purpose.
I am curious about the C++ Modules TS. I have played a little around with Clang's implementation. Only one or two files or so at a time.
Now I would like to try something bigger than that. And I would like to use CMake.
Does someone know if there is some good way to use the Clang modules implementation with CMake or are there already some CMake modules which help me with this?
I would really like to know. Otherwise I have to consider using a different build system.
I would suggest you try build2:
https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules
It supports modules for Visual Studio, gcc and clang. And for gcc there is a package that contains the standard library:
https://build2.org/pkg/hello/libstd-modules?f=full&q=library
Note that Microsoft implementation, as of Visual Studio 2017 update 4, is using the old syntax in the .ixx files (module xyz; instead of export module xyz; where the latter is what the last Modules TS draft mandates)
It shouldn't be any harder than configuring the proper command-line arguments. Since this feature has yet to be standardized and is different between the two known implementations (clang and MSVC -- gcc 7.2 documentation doesn't mention modules that I could find), I don't expect there are any CMake functions to handle anything.
AFAIK, the clang way of treating headers as special if they are in the module map file is lagging the current working draft for modules. IMO, it would be more useful to experiment with MSVC which is more closely tracking the WD for modules at this time. I don't know why g++ and clang are lagging here, they are usually early adopters. Perhaps it is because the specification is still in working draft stage and not yet a TS, I don't know.
When I am compiling my code with C++11 support (using the -std=c++11 flag) and use non-header-only Boost libraries, then I need to have Boost compiled with -std=c++11. This is because Boost has some interface differences in header files when C++11 is enabled, and some function signatures are different for the different C++ standards.
My question is whether the same is true with C++14 (using g++ 4.9, with the `-std=c++1y flag), or is it safe to use Boost compiled with C++11 for a program compiled with C++14?
This is a very broad question that is difficult to answer definitively, because
Boost is a federation of libraries, many of which are over decade old
there are quite a lot of backward compatibilities that could in principle happen, some detected by the compiler, and some only by unit tests
many Boost libraries are actually C++98 implementations of C++11/14 features (both library and compiler functionality), so that you would not need to use this in a C++11/14 project.
Boost itself is very much debating at which pace the library should be updated to C++11/14, whether V2 versions of libraries should be written that fully take advantage of C++11/14, and even whether new C++11/14 libraries should offer backward C++98 compatibility
You might want to closely read your compiler errors (if any) and compare them to the list of breaking changes listed below. Furthermore, I would recommend following the Boost test harness for finding suspect compiler/library combinations that apply to your system.
Some relevant Q&A's here:
What breaking changes are introduced in C++11?
What changes introduced in C++14 can potentially break a program written in C++11?
Relevant boost features vs C++11
How well does boost use c++11?
What is the extent of interoperability between C++11 and a recent version of Boost (say 1.55) built with a C++11 compiler.
Does the behavior of any library feature change depending on whether I built the libraries with c++11 flags enabled or not?
How do language features like lambda functions cooperate with Boost's lambdas?
You cannot use objects built with gcc with and without -std=c++11 together. You will get link errors or even runtime crashes. I cannot vouch for other C++ implementations. So at least with gcc, you do need to build a separate version of Boost with c++11 mode enabled.
They are pretty much independent. They don't cooperate and don't interfere with each other.
EDIT I see people are still reading (and upvoting!) this answer. Point 1 is no longer true (or perhaps never was true). Versions of gcc from I think 5.1 upwards use an ABI compatible with -std=<anything> by default.
No behaviours change: at the code level Boost is compatible with both C++03 and C++11.
However, at the object level you won't be able to mix and match: if your program is compiled as C++11, and you're using some non-header Boost libraries, you will have to build those Boost libraries as C++11 as well. This is because the respective C++ runtimes of your toolchain for each version of the language cannot be guaranteed to have ABI compatibility.
What is a good way of checking for the presence of specific C++11 features of the standard library.
For compiler features I just went by the way of checking the compiler version for the (IMHO) major compilers (VC++, gcc, clang at the moment, maybe Intel) Although this is not the best and most flexible approach, I don't know of anything better yet, except for clang which has the really nice __has_feature macros.
But it's even worse for library features, which are not coupled that rigidly to the compiler. At the moment I want to use the same approach of checking the compiler version for VC++ (where it's pretty easy, assuming it uses its own library). For clang I can at least use __has_include for large-scale header-based queries. Other than that I guess checking __GLIBCXX__'s value if defined might be a good idea, but then again I cannot find any information of what specific libstdc++ versions introduced which features, other than what the current version supports.
The methods should be kept to preprocessor checks and the like, since I want to use it in a header-only library without any sophisiticated configure procedure and without using any third-party libraries (and yes, boost is third-party).
So what are my possibilities of checking for specific C++11 library features under those (pretty narrow) conditions. Maybe even on the scale of particular functions or types being declared?
If checking for the compiler or library version is still the best approach, where can I find detailed information about the particular C++11 features supported by a specific version of libstdc++ (and maybe other important ones, libc++ perhaps)?
FWIW at the moment I'm interrested in <cstdint>, C++11 <cmath> functions and std::hash, but this may change and is probably not of importance for the general approach.
There is really nothing nice you can do here besides knowing which compiler in which version implements what and have the proper defines in place.
gcc has a special table for library functionality. The main problem of __has_include are of course additions to the standard that live in old includes. libstdc++ also has the necessary includes, but that doesn't mean the necessary define to enable the content of those files. It also wont tell you anything about the actual amount of available implementation (which sometimes is incomplete).
As you have a header-only library this doesn't apply to you, but is still important: binary incompatibility between C++11 and C++03 can come back and bite you.
I seriously wouldn't approach any of that on my own and rather use Boost.Config. Originally it only described language features but has now expanded to standard library headers.
You could write autoconf macros to check, and if you do, submit them to http://www.gnu.org/software/autoconf-archive/
The only relevant one so far checks for complete coverage, not for individual features: http://www.gnu.org/software/autoconf-archive/ax_cxx_header_stdcxx_0x.html#ax_cxx_header_stdcxx_0x
But that fails the requirement for no complicated configure checks.
Other than that I guess checking __GLIBCXX__'s value if defined might be a good idea,
Looking at the value of __GLIBCXX__ is not useful, it contains the date the version was released which tells you almost nothing about the version (e.g. 4.6.3 is released after 4.7.0 so has a later date in __GLIBCXX__ but has fewer C++11 features.) When using libstdc++ with GCC you want to use the general GCC version numbers in __GLIBC__ and __GLIBC_MINOR__ for checking versions (in general you can only use a given version of libstdc++ with the GCC release it came with.)
Edit: Starting with GCC 7 there is a new macro defined by the libstdc++ headers, _GLIBCXX_RELEASE, which is defined to the same value as GCC's __GNUC__, but is still usable even when using the libstdc++ headers with non-GCC compilers.
but then again I cannot find any information of what specific libstdc++ versions introduced which features, other than what the current version supports.
The libstdc++ C++11 status tables for previous releases are available online where all GCC docs live: http://gcc.gnu.org/onlinedocs/
For 4.7 it's at http://gcc.gnu.org/onlinedocs/gcc-4.7.1/libstdc++/manual/manual/status.html#status.iso.2011 and for 4.6 it's at http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/manual/manual/status.html#status.iso.200x and for previous releases is included with the source (but the coverage in pre-4.6 releases is pretty patchy anyway.)
Some added features are listed in the release notes for each version, e.g. http://gcc.gnu.org/gcc-4.7/changes.html (in the libstdc++ section)
Edit: For C++17 library support we now list which version first added the feature, so you only need to look at the latest docs: https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.201z
FWIW at the moment I'm interrested in <cstdint>, C++11 <cmath> functions and std::hash
They should be present in all versions of libstdc++ that have any C++0x/C++11 support.