Is there any official, or inofficial, #defines for when a compiler is Cpp0x compliant?
Even better, for specific Cpp0x functionality (~#cpp0xlambda, #cpp0xrvalue etc)?
(Haven't found anything about this on the net)
For C++03 according to 16.8/1 (Predefined macro names):
The name __cplusplus is defined to the value 199711L when compiling a C++ translation unit.
For C++0x draft n2857 according to 16.8/1 (Predefined macro names):
The name __cplusplus is defined to the value [tbd] when compiling a C++ translation unit.
Bjarne's C++0x FAQ says:
__cplusplus
In C++0x the macro __cplusplus will be set to a value that differs from (is greater than) the current 199711L.
The official spec includes a value for the __cplusplus preprocessor macro, but as others have pointed out, this suggests that everything in the spec is implemented. More to the point, no current compiler (that I know of) sets the appropriate value. Specs are well and good, but completely unimplemented bits of any spec should be considered tentative; the intersection of the spec and wide support is the real "standard".
A related question is "how can I tell if at least some C++0x support is enabled?", e.g. with the -std=c++0x compiler switch. The answer to that question is compiler-specific and subject to change, but both GCC 4.6 and Clang 2.1 set the preprocessor macro __GXX_EXPERIMENTAL_CXX0X__ (and give it value 1) when their partial C++0x support is enabled.
Related
I have a project which is strictly written in C++14 and I want to use it in another project which is C++17. Some of the C++14 features like Dynamic Exception Specification were removed in C++17.
Is there any way to use and compile both code bases together? The project is large enough to make refactoring impractical.
This will be platform specific: It is conceivable that substantially different headers are selected according to the standard specified on the command line, etc.
That said, here is an answer from Jonathan Wakely which assures you that with gcc there should be no such problem, by design, if you keep away from unstable features in old compilers.
The underlying reason according to Jonathan is that C++ standard implementations in gcc, once declared stable, do not change their ABI (i.e, outward-facing type definitions, name mangling) with the selected C++ standard, not even between compiler versions.
Because all interaction between the translation units must be restricted to the smallest common standard version there is no issue: The C++11 features do not change if you specify C++17. Newer features in the C++17 TUs cannot be used for communication with earlier-standard TUs since they were not yet available, so no issue there either. If you are able to recompile, the safest advice would be:
Best to use the same std::string versions (which can be controlled from the command line at compile time).
Use the same libstdc++.
Use the same gcc version (and control the language standard used for each TU through the command line).
It would make sense for other compilers to follow a similar compatibility strategy.
Yes, you can detect the C++ version and compile conditionally:
void foo() {
#if __cplusplus >= 201703L
// code written for C++17 goes here
#else
// code written for C++14 goes here
#endif
}
The full list of __cplusplus macros is as follows:
#if __cplusplus >= 199711L // C++98
#if __cplusplus >= 201103L // C++11
#if __cplusplus >= 201402L // C++14
#if __cplusplus >= 201703L // C++17
#if __cplusplus >= 202002L // C++20
Note that this causes various problems:
it's impossible to test code like this unless you compile your tests for C++14 and C++17 separately
your IDE might not even show warnings or errors in removed preprocessed blocks
you need to maintain two separate version of the same code
So if you can, come up with a solution that works in both versions or at least use as few blocks like this as possible. If you just want a single keyword or so to be removed, then consider the following solution:
#if __cplusplus >= 201703L // C++17
#define THROWS(exception) noexcept(false)
#else
#define THROWS(exception) throw(exception)
#endif
// now you can use it like this in both C++14 and C++17:
void fun() THROWS(MyException);
I would like to use the generalized lambda capture introduced in C++14 (see Move capture in lambda for an explanation). However, the remainder of my code is C++11-friendly. I would like to do something along the lines of
#ifdef CPP14
// move capture in lambda
#else
// capture by-value
#endif
However, there are no good cross-compiler flags to infer versions. Is there anything anyone can suggest? (other than, of course, defining my own macros)
Actually T.C. is right, the C++11 FDIS says in "16.8 Predefined macro names [cpp.predefined]" that
The name __cplusplus is defined to the value 201103L when compiling a C++ translation unit.
The footnote states:
It is intended that future versions of this standard will replace the value of this macro with a greater value. Non-conforming com- pilers should use a value with at most five decimal digits.
So going with the following code seems totally legit to me.
#if __cplusplus > 201103L
//c++1y or above
#else
//c++11 or below
#endif
However, some compiler might not follow the standard and you might want to check if the _cplusplus value has been incremented for c++1y.
The GCC, for example, had this flag set to 1 until the version 4.7.0.
If you need more information on the _cplusplus flag, you should take a look at this question
I want to use some C++11 features in my program. I might have to share my source code with others in future. How do I assert, inside the code, that C++11 should be used to compile my program? An older compiler might throw an error, but I want the user to be informed clearly that C++11 is required.
I'm using the following C++11 features, if that matters:
enum with storage size specified
std shared pointer
thanks
You could check that the value of the __cplusplus macro is 201103L or greater:
#if __cplusplus < 201103L
#error This code requires C++11
#endif
C++11 16.8 Predefined macro names:
The following macro names shall be defined by the implementation:
__cplusplus
The name __cplusplus is defined to the value 201103L when compiling a C++ translation unit. (155)
(155) It is intended that future versions of this standard will replace the value of this macro with a greater value. Non-conforming
compilers should use a value with at most five decimal digits.
__cplusplus macro may come handy
#if __cplusplus < 201103L
#error C++11 Required
#endif
Something like this
As it has already been said, the correct solution would be to check for the __cplusplus macro. However, some compilers have a partial support for C++11 features but do not set this macro for the correct value. For example, strongly-typed enumerations are available in g++ since GCC 4.4.0. However, with the option -std=c++11 (and its equivalents), the macro __cplusplus was not set to the good value before GCC 4.7.0 (it was set to 1 instead). That means that some compilers can compile your code but won't if you check for C++11 that way.
If you just need specific features, then I would check for them with Boost.Config which defines a whole set of macros that can be used to check whther your compiler supports the required features. In your case, you would need:
BOOST_NO_CXX11_SCOPED_ENUMS for strongly-typed enumerations.
BOOST_NO_CXX11_SMART_PTR for std::shared_ptr.
Are there any predefined macros for C++ in order the code could identify the standard?
e.g. Currently most compilers puts "array" into "tr1" folder but for C++11 it would be part of STL. So currently
#include <tr1/array>
but c++11
#include <array>
What is the predefined macros for 03 standard and 11 standard in order I can use #ifdef to identify?
Also, I suppose there are macros for C90 and C99?
Thanksx
From Stroustrup's C++11 FAQ
In C++11 the macro __cplusplus will be set to a value that differs from (is greater than) the current 199711L.
You can likely test it's value to determine if it's c++0x or not then.
Nitpick...
Your particular issue does not depend on your compiler, it depends on the Standard Library implementation.
Since you are free to pick a different Standard Library that the one provided by your compiler (for example, trying out libc++ or stlport), no amount of compiler specific information will help you here.
Your best bet is therefore to create a specific header file yourself, in which you will choose either one or the other (depending on a build option).
// array.hpp
#ifdef STD_HAS_TR1_ARRAY_HEADER
#include <tr1/array>
#else
#include <array>
#endif
You then document the compiler option:
Passing -DSTD_HAS_TR1_ARRAY_HEADER will mean that std::tr1::array is defined in <tr1/array> instead of the default <array>.
And you're done.
From the draft N3242:
16.8 Predefined macro names [cpp.predefined]
...
The name _ _ cplusplus is defined to the value 201103L when
compiling a C++ translation unit. 155)
...
155) It is intended that future versions of this standard will
replace the value of this macro with a greater value.
Non-conforming compilers should use a value with at most five
decimal digits.
Ultimately, you're going to have to use compiler-specific information. At least, until C++0x becomes more widespreadly implemented. You basically need to pick driver versions that implement something and test compiler-specific macros on them.
The Boost.Config library has a number of macros that can help you.
I am wondering how different the preprocessors for C++ and C are.
The reason for the question is this question on a preprocessor-specific question where the paragraph of the standard that addresses the question has a different wording (and a different paragraph number) and also are difference concerning the true and false keywords in C++.
So, are there more differences or is this the only difference.
An extension of the question would be when is a source file emitted differently by a C++ preprocessor and a C preprocessor.
The C++03 preprocessor is (at least intended to be) similar to the C preprocessor before C99. Although the wording and paragraph numbers are slightly different, the only technical differences I'm aware of between the two are that the C++ preprocessor handles digraphs (two-letter alternative tokens) and universal character names, which are not present in C.
As of C99, the C preprocessor added some new capabilities (e.g., variadic macros) that do not exist in the current version of C++. I don't remember for sure, but don't believe that digraphs were added.
I believe C++0x will bring the two in line again (at least that's the intent). Again, the paragraph numbers and wording won't be identical, but I believe the intent is that they should work the same (other than retaining the differences mentioned above).
They are supposed to be the same: C++98 and C++03 should match C90, and C++0x should match C99. There may be bugs in the wording, though.
Predefined macros differ between the preprocessors, mostly for obvious language feature differences. E.g. compare:
C99 N1256 draft 6.10.8 "Predefined macro names"
C++11 N3337 draft 16.8 "Predefined macro names"
In particular:
C requires you not to define __cplusplus, C++ uses it to represent the version
C uses __STDC__ to represent the version, C++ says is implementation defined and uses __cplusplus instead
C has __STDC_IEC_559__ and __STDC_IEC_559_COMPLEX__ to indicate floating point characteristics, C++ does not and seems replace that with the per type std::numeric_limits<float>::is_iec559 constants
C does not have the macros prefixed with __STDCPP: _STDCPP_STRICT_POINTER_SAFETY__ and __STDCPP_THREADS__
As mentioned by DevSolar, C11 added many more defines which are not part of C++11.