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.
Related
I have a QNX specific code and I want to use clang-tidy for static analysis. Is this possible?
I am struggling because clang-tidy is supported by the clang compiler, and QCC (QNX compiler) is based on GCC.
Potentially yes. clang-tidy works with C++ source files and it mostly doesn't matter what compiler you use. As long as your program would compile with Clang, you can use clang-tidy.
However, although Clang is mostly compatible with GCC, the compatibility is not 100% proof and it may be confused if you use GCC / QCC specific features that are foreign to Clang. With standard, non-experimental C++ there should not be a problem.
Another consideration is that clang-tidy is typically used in conjunction with "compilation database", which invokes it with exact compiler options that you use to compile the program. Here again, Clang supports most GCC options either fully, or ignores them for compatibility, but some new, obscure or QCC specific options do cause an error.
I am using Eclipse CDT 3.8.1 with GCC Cross Compiler 8.6.0. I know how to change the C++ standard in the project properties, but I don't know what standard is used by default.
I know the default is not C++11 and the Eclipse language support page doesn't mention C++03, so I suspect the default is C++98. However, Eclipse CDT must support C++03 because adding the compiler flag -std=c++03 doesn't cause any errors.
https://www.eclipse.org/community/eclipse_newsletter/2017/april/article3.php
What is the default standard when I create a new project?
Eclipse's parser itself doesn't have a notion of a C++ standard mode. It will recognize all the C++ features that have been implemented in its parser (which, as of writing this, is all C++98 and C++11 features, some (but not all) C++14 features, and a handful of C++17 features).
However, standard library headers often contain sections that are conditional on macros denoting the C++ standard version (e.g. #if __cplusplus >= 201103 is a common check for "C++11 or later"). To determine the value of these macros, Eclipse invokes the compiler specified in the project's toolchain to discover built-in macros. The discovered value of e.g. the __cplusplus macro will depend on what standards mode the compiler runs in for this invocation.
The flags to this compiler invocation are specified in the project properties, as you mentioned. If you don't provide a flag there, the compiler will use whatever its default mode is. I believe GCC has been using -std=c++14 as the default from GCC 6 onwards. (Though I don't quite know what "GCC Cross Compiler 8.6.0" is. According to the GCC website, the latest version is 8.1.)
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.
What are the differences between -std=c++11 and -std=gnu++11 as compilation parameter for gcc and clang? Same question with c99 and gnu99? I know about C++ and C standards, it's the differences in the parameters that interest me.
I've read somewhere that it has to do with some extensions but it is not clear to me which ones and how to choose between one or the other for a new project.
As you have found out yourself, the difference between the two options is whether GNU extensions that violates/extend the C++ standard are enabled or not. The GNU C++ extensions are described here. You can also use most of the GNU C extensions (described here) in your C++ programs. It would be also useful to read about the -Wpedantic GCC option here.
Note that some extensions can still be in effect when using -std=c++11, as long as they do not contradict the standard. For instance, when using the MinGW compiler, I need the extensions for a working Boost.Lexical_Cast. But, as long as you don't use any of them, you are better off sticking to the standard without extensions for maximum portability. This might come in handy if you find yourself forced to change compiler.
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.