Menu
If have some code where I would like to use C++11x extensions as much as possible, but have a fallback if this is not supported. Currently the OSX version of GCC and the VisualC compiler has little to no support for C++11x, so I use:
#if (defined(__APPLE__) || (defined(_WIN32))) ...fallback code without C++11x ... #else ... code using C++11x ... #endif And this works, but is not really the right thing to do, especially since the gcc compiler in MacPorts DOES support c++11x.
Is there a #define C11X_SUPPORTED type macro? Perhaps something only GCC has?
658
To see if your compiler has C++11 support, run it with just the --version option to get a print out of the version number. Do this for whichever compiler(s) you wish to use with Rosetta. Acceptable versions: GCC/g++: Version 4.8 or later.
Description. In the C Programming Language, the #include directive tells the preprocessor to insert the contents of another file into the source code at the point where the #include directive is found.
C++17 Support in GCC C++17 features are available since GCC 5. This mode is the default in GCC 11; it can be explicitly selected with the -std=c++17 command-line flag, or -std=gnu++17 to enable GNU extensions as well.
There are 4 Main Types of Preprocessor Directives:Macros. File Inclusion. Conditional Compilation. Other directives.
__cplusplus should be defined as 199711L in pre-C++11 compilers, 201103L in those suporting C++11. Whether this is much help in practice is another question: most compilers are only halfway there, so shouldn't be defining it as 201103L, even if they support the features you are interested in. And it's not unheard of for a compiler to lie: a compiler which defines it as 199711L and doesn't support export for templates, for example. But there's no standard feature by feature test.
The simplest solution is just not to use any particular new feature until you can be sure that all compilers support it. You have to write and support the fallback code anyway; why maintain two versions. The one exception to this rule might be new features which impact on performance: whether the compiler supports move semantics or not. In such cases, I'd suggest a compiler dependent include file, which you write yourself based on the compiler documentation and personal tests; just because the compiler may document that it supports a specific feature doesn't mean that its support is bug-free. Just create a directory per targeted compiler, put this file there and specify the appropriate -I or /I option in your makefile or project file.
And your tests should be something along the lines of:
#ifdef HAS_MOVE_SEMANTICS ... #endif rather than just on the compiler, version or whatever.
95
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
