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:.
Related
While trying to compile a simple range based for loop on MacOS Big Sur, I got this warning:
warning: range-based for loop is a C++11 extension [-Wc++11-extensions]
I tried using clang++ and g++ but both gave the same warning. Is there a way to always compile with C++11 without having to use -std=c++11 and without using aliases?
Edit: The reason I would prefer not to use -std=c++11 is because I want the compiler to default to C++11 or higher.
To provide this question with a proper answer, based on the discussion in the comments:
Compilers such as GCC and Clang set the default in their source code and it cannot be changed by, e.g., modifying a config file. The only way to change the default would be to change it in the source code and to compile the compiler yourself. This is not worth it.
Furthermore, compilers change their default language from time to time, and setting another default, e.g. to C++11, will make all non-C++11 code require setting the language version explicitly.
Here's the key point: code and compilation options belong together. Do not rely on compiler defaults. Any serious project will use a build system (e.g. Make) which specifies how to compile the project.
Edit
For completeness sake, the default C++ version for GCC 10.2.0 is hardcoded in /gcc/c-family/c-opts.c:
/* Set C++ standard to C++17 if not specified on the command line. */
if (c_dialect_cxx ())
set_std_cxx17 (/*ISO*/false);
This question already has an answer here:
Compiling issue with ifort composer_xe_2015.3.187
(1 answer)
Closed 7 years ago.
I am using a numerical model that is sensitive to the precision of numerics. With my old ifort compiler I successfully used the Fortran flags
"fp-model precise"
I recently installed intel compiler composer_xe_2015.3.187. It does not recognize the Fortran flag
"fp-model precise".
This is the exact error that I get
f95: error: precise: No such file or directory
f95: error: unrecognized command line option ‘-fp-model’
I am afraid if I would be sacrificing my efficiency in lieu of the new compiler or is the new one inherently able to maintain precision.
The compiler you are invoking with the name f95 is not Intel Fortran. Based on the error message, I'm guessing it is actually the GNU Fortran compiler, but you can check for sure by running f95 -v to see what the compiler identifies itself as.
Intel Fortran 15 still supports the option -fp-model precise.
Before invoking ifort, you need to setup its environment, e.g.
source /path/to/intel/bin/ifortvars.sh intel64
for the 64 bit compiler. You can then invoke the compiler as ifort.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
gcc preprocessor output
For some reason I need to investigate some .i files generated by g++ preprocessor, where I see code like this:
#1 /usr/local/include/boost/python.hpp 1 3
#11 /usr/local/include/boost/python.hpp 3
I'm an experienced C++ programmer and I know what .i file is, the problem is, I can't find a detailed explanation on how to interpret the lines in .i file.
Can someone explain what the above lines mean (especially what the numbers following the files ) or point me a place where I can find some document about this?
Thanks, after looking at the link, my problem solved. I'd like to add some background in case somebody else see the same problem.
My project uses a strict compiler check, i.e., g++ -Wall -Werror. All warnings are treated as errors. And we are using boost.python, before yesterday, boost was put in /usr/local/include, and the compilation is fine. Then we decide to move boost into our source control for easier upgrade, and a warning (treated as error) arise.
So after the investigation and the details from the link given by CrazyCasta, the problem is actually this: when boost is in /usr/local/include, it is treated as a system header, so gcc supresses some warnings; while we move boost out, gcc is not that tolerable to it.
Basically, just ignore or supress that warning by hand.
Your answer can be found here.
Basically it's remapping the line number/filename space of the input so the compiler knows where lines came from. The first number is the line number of where the source came from, the filename after that is the file it came from. The numbers thereafter are flags.
This question already has answers here:
Autotools check for C++11
(2 answers)
Closed 9 years ago.
I have a project configured via Autoconf, and I want to start using C++11 features in this project. How to have the "-std=gnu++0x" switch always enabled and support for the features checked while configuring?
Have you checked ax_cxx_compile_stdcxx_11 ?
I think this is exactly what you want.
There is a big macro library on gnu website.
You can do this with something like AX_CHECK_COMPILE_FLAG, e.g.:
AX_CHECK_COMPILE_FLAG([-std=c++0x], [
CXXFLAGS="$CXXFLAGS -std=c++0x"])
(You need to be careful here that AC_LANG is C++, not C at the point this is called because it's possible to use gcc for C and something else for C++ or vice versa).
I think the simplest way to do this is to add:
CXXFLAGS="$CXXFLAGS -std=c++0x"
in configure.ac before AC_PROG_CXX. If the compiler does not accept -std=c++0x, then configure will fail with "C++ compiler cannot create executables". It is not the best error messages, but it ensures that builds will succeed if configure succeeds. For a better error message, you can check that the compiler accepts the flag after AC_PROG_CXX. In either case, you want configure to fail if the compiler does not provide the necessary features but your software requires it.
Note that setting CXXFLAGS before AC_PROG_CXX has the undesirable side effect of preventing the default setting for CXXFLAGS in the case that the user does not set that variable when running configure. For this reason, it is normally not recommended to set CXXFLAGS in the configury, so it is probably better to check the flag after AC_PROG_CXX (eg using awoodland's solution)--just make sure you add an AC_MSG_ERROR in the third argument of AX_CHECK_COMPILE_FLAG so that configure fails if the features are not available.
To enable the compiler switch (unless, of course, the user overrides it), put this in your Makefile.am:
AM_CXXFLAGS=-std=c++0x
I don't think there's a check available for the presence of C++11 features, but you should be able to write a test program fairly easily with the features you want to use, that will fail if those features are not supported. Then you can write a test as described in this section of the Autoconf manual.
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.