I'm using some features in my C++ programs that I need -std=c++11 option set in g++
Is it possible set this option as a default and don't be necessary use this all time I compile it?
Or how to set this in Makefile.
Yes, you typically set this in a Makefile:
CXXFLAGS=-std=c++11
One layer above you can also detect a suitable compiler via autoconf, cmake or whichever other meta-buildtool you might deploy.
You of course play games as define g++11 as g++ -std=c++11 but such set-ups are not portable.
g++-6.* will default to c++14 so at some this switch will be implicit. But it might take a really long time for all those RHEL and CentOS boxen with g++-4.4.* to disappear. Those may not even handle your current project...
Yes, upgrade to GCC 6.1:
The C++ frontend now defaults to C++14 standard instead of C++98
From https://gcc.gnu.org/ml/gcc/2016-04/msg00244.html
You can have a makefile do this as follows (this is a simple version with no variables).
out: source.cpp
g++ -std=c++11 source.cpp -o out
Use your build system of choice. Be that make, SCons, CMake, qmake or something else, and set the required option. Should take all of 30 seconds and you're done.
Or, upgrade your compiler to a version that uses C++11 by default.
Related
CMake has a nice framework for setting and defining an explicit value for the C++ standard, typically:
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_EXTENSIONS OFF)
However this does not clearly fit my needs, I'd rather states that I need at least c++11. I thought that I could just do instead:
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.7)
project(p CXX)
set(CMAKE_CXX_EXTENSIONS OFF)
add_executable(foobar foobar.cxx)
target_compile_features(foobar PRIVATE cxx_nullptr)
where
$ cat foobar.cxx
int main()
{
char * p = nullptr;
}
However again in this case this forces me to use -std=c++11 eventhough by default g++ 6.3.0 default to -std=c++14 (technically -std=gnu++14):
$ c++ -dumpversion
6.3.0
leads to:
$ make VERBOSE=1
[...]
make[2]: Entering directory '/tmp/p'
[ 50%] Building CXX object CMakeFiles/foobar.dir/foobar.cxx.o
/usr/bin/c++ -std=c++11 -o CMakeFiles/foobar.dir/foobar.cxx.o -c /tmp/p/foobar.cxx
[100%] Linking CXX executable foobar
/usr/bin/cmake -E cmake_link_script CMakeFiles/foobar.dir/link.txt --verbose=1
Is there a way to say: "Build this project with at least C++11 Standard" in CMake ?
Typically for a project built using g++ 4.8.5 it would add -std=c++11 but for a project build with g++ 6.3.0 it would leave the default (implicit) -std=c++14
Update: The following is out of the scope for the question, but since I received a lengthy answer from #ComicSansMS, I feel I need to clarify the need for this.
I am working with my Debian Maintainer hat on, and I was convinced a couple of months back that setting an explicit C++ standard version in cmake within a project was the right way to do, hence my proposal:
Mandates explicit -std=c++XY for c++ projects
However there are two things that get mixed here:
Defining a c++ standard version for the interface of the library being built
Defining a c++ standard version for the implementation detail of the library being built.
From a Debian Maintainer perspective setting explicitly a C++ standard version makes it hard to rebuild a portion of the package archive when a library SONAME is being updated. Let's consider the case where GDCM is using the Poppler library. While the implementation details of GDCM are written using C++98, the fact that Poppler library has been build using the default (implicit) standard version of gcc-6 makes it suddenly a compilation failure for GDCM, since an explicit -std=c++98 is being passed.
So while for an implementation prospective, setting an explicit c++ standard version make sense (obviously!), it is a little less clear for an interface prospective. The vast majority of open-source projects do not define multiple c++ ABI (std::string[98] AND std::string[11]) and assume a single version will be used to ship the binary. In this case it makes it important for a c++ package to be build using the default (implicit) version of gcc (at least when uploaded as official Debian package).
You can always test for compilers support of the specific standard flags yourself.
First check for -std=c++14, and if it doesn't exist then check for -std=c++11, and if that doesn't work then error out.
Flags can easily be checked with the CheckCXXCompilerFlag module.
These days you should probably start with -std=c++17 though. You might also want to add checks for the pre-release standard versions like c++1z (for C++17) and c++1y (for C++14).
Start with the highest version, then work your way downward the minimum required version. Stop when it doesn't fail.
For newer versions of CMake you could use target_compile_features to specify features that the target compiler should be able to provide for.
This way, if (for example) your project uses auto type deduction you could tell CMake that the compiler need to suport the cxx_auto_type feature. Then CMake will make sure that the compiler can indeed support C++11 and the auto type deduction.
Is there a way to say: "Build this project with at least C++11 Standard" in CMake ?
No, and this is probably not a reasonable thing to request.
It does not make any sense to request a standards version that is newer than the code you are trying to build, as your code will not make any use of those features anyway.
The other big problem here is that newer standards are not strict supersets of older standards. In recent versions, the C++ standard has been quite keen on deprecating and even removing features that have outlived its usefulness.
What you have is a specific piece of code that expects a specific set of language features to be available. And that is exactly what you should tell the buildsystem. If your code expects the C++11 features to be available, set CMAKE_CXX_STANDARD to 11 and be done with it. It will guarantee that all of the required features are available and safeguard you (within reasonable bounds) against any future deprecations.
Now, there is one scenario where specifying an exact standard is not enough: You might have different implementations in your code and then want to switch between implementations depending on the available compiler capabilities. That is, your code might be C++14 aware and you want it to compile in C++14 mode if available, but still leave the C++11 mode as a fallback.
This is exactly the default behaviour of CMAKE_CXX_STANDARD:
This means that using:
set_property(TARGET tgt PROPERTY CXX_STANDARD 11)
with a compiler
which does not support -std=gnu++11 or an equivalent flag will not
result in an error or warning, but will instead add the -std=gnu++98
flag if supported. This “decay” behavior may be controlled with the
CXX_STANDARD_REQUIRED target property.
So in a nutshell, always specify the latest standard that your code is aware of, but not newer.
I try to compile a robot for torcs with the usage of opendavinci. The problem is that everytime i try to compile it
#error This file requires compiler and library support for the ISO C++ 2011 standard
appears. The obvious solution is to add the support, but i have a complicated makefile that is from torcs so i dont know how to work around this problem.
Is there any way to add the support without changing the makefile? I read about the CXXFLAGS that coud help me but i dont understand how it works.
The compiler is g++ 5.4.0 for Ubuntu
felix#ubuntufelix:/usr/src/torcs/torcs-1.3.7/src/drivers/bt$ make
g++ -I/usr/src/torcs/torcs-1.3.7/export/include -I/usr/src/torcs/torcs-1.3.7 -g -O2 -Wall -fPIC -fno-strict-aliasing -O2 -DUSE_RANDR_EXT -DGL_GLEXT_PROTOTYPES -Wall -fPIC -fno-strict-aliasing -O2 -DUSE_RANDR_EXT -DGL_GLEXT_PROTOTYPES -D_SVID_SOURCE -D_BSD_SOURCE -DSHM -DHAVE_CONFIG_H -c driver.cpp
In file included from /usr/include/c++/5/array:35:0,
from driver.h:15,
from driver.cpp:1:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
There's no completely standard way to build distributed software, but there should be a README or INSTALL file in the distribution, which gives more-or-less precise instructions. Ideally, distributions come with a configure script, and the installation process consists of ./configure; make; make install, possibly with some per-distribution special options given to ./configure. The basic process here is that the ./configure script edits suitable values into Makefile.in to generate Makefile, but such scripts can be arbitrarily complicated. Of course, things are rarely quite that simple, and building complicated software from source can be quite a technical challenge (this is why package managers are a Good Thing).
If there are no such installation instructions (have you double-checked?), then you should go back to the software distribution point and ask for help there (you're allowed to have a hint of reproach in your question as you do so – everyone, distributing even pre-beta software, should tell users how to build things).
If you've been left high and dry, however, then the following should broadly indicate where to look next:
You need to add an option to the invocation of the compiler, to tell it to support C++ 2011 features (I'm pretty sure g++ 5.4 has these features available, but they aren't enabled by default).
You do that by adding the -std=c++11 option to the compiler flags, and the way you do that is using the CXXFLAGS makefile variable that you measured (note: CXXFLAGS is the probable/conventional name for this variable, but it's not an inviolable rule).
Depending on how the Makefile is structured, you can add or adjust that variable in a number of ways.
Edit the Makefile – search for CXXFLAGS in the Makefile and add that -std option to that definition.
You will be able to redefine the variable on the make command line: make CXXFLAGS=-std=c++11, but that will stomp on any definition within the Makefile, which might be important.
The Makefile might be structured so that the definition includes CXXFLAGS=-foo -bar $(EXTRA_CXXFLAGS), which is there precisely so that you can call make with make EXTRA_CXXFLAGS=-std=c++11.
If there's a ./configure step to building this software, then there may be an option available to ./configure when doing that step (that doesn't sound like the case here).
But one way or another, your goal is to get -std=c++11 appearing in the compiler invocation that's produced by the Makefile. Note that if you give the -n option to make, then it will show you what commands it would produce, without actually doing anything.
Have fun.
I'm doing a tutorial right now that doesn't make it to clear on how to do this.
I have two files, int2.cpp which has my main and int1.cpp which is a function (int2 calls on int1) I know they will work but how would one type it into the command line? tutorial says g++ int2.cpp int1.cpp -o int2.cpp, but it says " g++ is an illegal command"
I'm using DOSbox 0.74.
I compile things with tcc sorry but it says -o isn't a command line option
I compile things with tcc sorry but it says -o isn't a command line option
TurboC++ is an obsolete compiler (for an obsolete variant of C++); don't use it.
TinyC (e.g. the tcc command) is a compiler for C, not for C++.
C and C++ are different languages, and you want to learn at least C++11 (since older standards of C++ are obsolete and very different, it is not worth learning them in 2017).
So get and use a free software C++11 compiler like GCC or Clang. BTW both are easily available on most Linux distributions (which I recommend you to use).
Of course you'll want to compile with warnings and debug information, so use
g++ -Wall -Wextra -g with GCC and clang++ -Wall -Wextra -g with Clang.
BTW, you probably want to compile several translation units into a single executable binary. This often involves a linking step (i.e. running the linker on several object files, also using the g++ command). Consider learning to use some build automation tool like GNU make (which has a lot of builtin rules to help in doing that).
g++ is an illegal command means the compiler is not installed on your path. The syntax is (almost) right, you likely just don't have gcc installed.
g++ int2.cpp int1.cpp -o int2.exe
I am cross compiling some code from Windows on Linux machine (Kubuntu 16.05),g++ 5.4.0 64bit. Using Code Lite IDE as a dev env.
I have got several lines of code where I init unique pointer with
std::make_unique
The compiler complains with the error:
error: 'make_unique' is not a member of 'std'
I tried to add <memory> as well as <unique_ptr.h> to the header. Then the compiler complains that it can't find <unique_ptr.h> file. Interestingly,when I click to open the file from within the editor it is found and opened. The file is located in /usr/include/c++/5/bits/unique_ptr.h
I made sure that the compiler version that builds the code is indeed 5.4, so I don't understand why it doesn't support unique_ptr out of the box.I make sure to enable C++11 and C++14 flags:
-g;-O0;-std=c++14;-std=c++11;-Wall
Also, in the includes I add /user/include
What am I missing here? Do I have to include in the project the /usr/include/c++/5/bits/ directory explicitly?
Try these flags:
-g -O0 -std=c++14 -Wall. Note that semicolon is not needed for separating flags.
Compiler will take the latest entry of -std so you are effectively compiling with C++11 but not C++14.
As you can see HERE enabling -std=c++11 after a newer standard disables the first declared standard. Enabling only C++14 is enough.
C++11 introduced std::unique_ptr, but there was no std::make_unique (this broke the "symmetry" of shared_ptr/make_shared).
They fixed that in C++14, adding std::make_unique.
So, if you compile your code in C++11 mode, you can't use std::make_unique.
As others already pointed out, you need to set the latest C++ standard with the -std compiler option; in this case, it's -std=c++14 to enable also std::make_unique.
I want to play with C++ 2011, so I need the unreleased gcc 4.7. I was able to succesfully get the svn trunk and compile it.
I want to keep the default gcc of my system for safety, so I configured gcc4.7 with a --prefix and installed it in a non-standard location.
Now how should I enable gcc 4.7 over the default gcc of my system ?
I already changed the CC and CXX variables, I updated my PATH to point on the gcc 4.7 bin dir first. When I type gcc --version I get 4.7 OK.
But gcc is more than just an executable. There are many executables in gcc install dir. There are also default includes and std lib c++.
So far, every blog entry / SO question I found on this subject speaks only about the gcc and g++ executables.
Can anyone give me a list of the changes I need to do to the environment to fully use gcc 4.7 ?
update LD_LIBRARY_PATH ? How to give precedence to gcc 4.7 system includes ? Are there other things to consider ?
Thanks in advance.
I would think that THE g++ is pretty much tangled up with things using C++ as the C library is tangled up with the system! Any layout changes in the C++ library classes will cause incompatibilities with other C++ programs or libraries. Thus, I wouldn't replace the system's C++ compiler or, more importantly, its standard C++ library at all (unless, maybe, the compiler vendor makes a strong claim that they retained binary compatibility with the version you are replacing).
To play or even use a different version of g++, using the prefix approach works fine. All the compiler specific tools are implicitly called from within g++ using an appropriate version and tools like ar, ld, ranblib, etc. are not really depending on the compiler version anyway. The important components uses internally are the standard library (both the headers and the library) and the preprocessor. When calling a version of g++ it figures out which of these it really needs.
BTW, when you want to play with C++2011 you can also have a look at clang.
The simplest answer is: nothing; it just works. :)
GCC finds what it needs first relative to itself, second in the "prefix" it was configured with, and finally in the standard places. By this means it's perfectly safe to relocate it wherever you like, as long as you relocate all of it - but beware that the fall back behaviour can hide brokenness if the install is incomplete.
Look at the GCC Configuration docs. I am using program suffixes to distinguish between the different GCC versions. To do that add, e.g., --progam-suffix=-4.7 to your ./configure invocation.