This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
GNU C++ how to check when -std=c++0x is in effect?
What I want to do is:
#if defined(CPLUSPLUS_OXFLAG)
//do something
#else
//do something else
#endif
Now how can I capture -std=c++0x argument passed to the compiler(g++) to define my CPLUSPLUS_OXFLAG flag?
The GCC documentation states that the preprocessor symbol __GXX_EXPERIMENTAL_CXX0X__ is defined when compiling with -std=c++0x.
For GCC have a look at this:
__GXX_EXPERIMENTAL_CXX0X__
This macro is defined when compiling a C++ source file with the option -std=c++0x or -std=gnu++0x. It indicates that some features likely to be included in C++0x are available. Note that these features are experimental, and may change or be removed in future versions of GCC.
Find the reference here.
GCC defines __GXX_EXPERIMENTAL_CXX0X__ when std=c++0x is enabled.
Related
This question already has answers here:
How do I check for C++11 support?
(9 answers)
Closed 1 year ago.
How do I check during compilation that GCC (or any other compiler) has at least C++17 running? Can you give a minimal preprocessor snippet that emits an error if the version is below C++17?
I presume this can be built from __cplusplus and the #error directive.
#if __cplusplus < 201703L
#error "C++17 or later is required!"
#endif
This question already has answers here:
How can I completely disable calls to assert()?
(5 answers)
Closed 6 years ago.
Are asserts disabled in 'release' build?
How optional flags like -O0,-O3,-g of g++ affects it's behaviour?
assert() in the <cassert> header is only disabled if you define the macro NDEBUG prior to including the <cassert> header file. See also these docs
With gcc/g++, the easiest way to do so is to define the NDEBUG macro on the command line when invoking the compiler like so:
g++ -DNDEBUG ... other args...
Arguments such as optimization flags and similar flags does not disable the assert.
From the man page:
If the macro NDEBUG was defined at the moment assert.h was last
included, the macro assert() generates no code
This question already has answers here:
Why C++11 compiler support still requires a flag?
(2 answers)
Closed 8 years ago.
As in title. Will it be default or to use C++11 features we will always have to add -std=c++11?
Right now, because of this option, C++11 still feels like some extra, non-standard thing.
To specify compiler, -std=c++11 flag is used by clang, g++ and even ICC.
With g++, use -dumpspecs to generate a specs file.
Use -print-search-dirs and first line is where to place specs file.
Add the -std=c++11 option appropriate place in specs file, on the line following *cc1plus:.
This question already has answers here:
Why C++11 compiler support still requires a flag?
(2 answers)
Closed 8 years ago.
Every time I use one of the new classes C++11 offers like chrono.h and compile it with GCC it warns me that C++11 functions are still experimental and must be enabled with a special flag to be usable.
Its end 2014 at the moment of writing this, how come that after atleast 3.5 years GCC is still marking C++11 as "experimental" , are, after all those years, some functions that C++11 offers us still not implemented?
If thats the case, how come?
Code :
#include <chrono>
#include <thread>
int main()
{
std::this_thread::sleep_for(std::chrono::milliseconds(3000));
return 0;
}
compiler line :
g++ Source.cpp -o test.exe
GCC version :
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc.
GCC spits out :
C:/Program Files/mingw-w64/x86_64-4.9.2-posix-seh-rt_v3-rev0/mingw64/x86_64-w64- mingw32/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires G compiler and library support for the ISO C++ 2011 standard. This support is curr ently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 comp iler options.
Once I add. '-std=c++11' to the compiler options I no longer get the error/warning message but I was already aware of that. I was puzzled as to why it did give me a warning without adding it. Shouldn't the current std on GCC be C++11 already? Why is this still not the case?
Software and build systems out there use the defaults and expect them to remain fairly stable. GCC does not simply update the default settings every time new standards or features are available.
If you want a particular version of the standard then you should specify it explicitly.
The Gnu C++ compiler seems to define __cplusplus to be 1
#include <iostream>
int main() {
std::cout << __cplusplus << std::endl;
}
This prints 1 with gcc in standard c++ mode, as well as in C++0x mode, with gcc 4.3.4, and gcc 4.7.0.
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. (Footnote: 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.)
The old std C++03 had a similar rule.
Is the GCC deliberatly setting this to 1, because it is "non-conforming"?
By reading through that list I thought that I could use __cplusplus to check in a portable way if I have a C++11 enabled compiler. But with g++ this does not seem to work. I know about the ...EXPERIMENTAL... macro, but got curious why g++ is defining __cplusplus this way.
My original problem was switch between different null-pointer-variants. Something like this:
#if __cplusplus > 201100L
# define MYNULL nullptr
#else
# define MYNULL NULL
#endif
Is there a simple and reasonably portable way to implement such a switch?
This was fixed about a month ago (for gcc 4.7.0). The bug report makes for an interesting read: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
If I recall correctly this has to do with Solaris 8 causing issues when __cplusplus is set as it should. The gcc team decided at the time to support the Solaris 8 platform rather than be compliant in this particular clause. But I noticed that the latest version of gcc ends the Solaris 8 support, and I guess this is a first step in the right direction.
It is a very old g++ bug.
That is, the compiler is not conforming.
Apparently it can't be fixed because fixing it would break something on a crazy platform.
EDIT: oh, I see from #birryree's comment that has just been fixed, in version 4.7.0. So, it was not impossible to fix after all. Heh.
Cheers & hth.