Including C++11 header file with in C++ source file - c++

I'm trying to figure out how to make use of C++11 headers in my C++ project. Specifically I'm trying to use FakeIt mocking framework (https://github.com/eranpeer/FakeIt) for unit testing my legacy application which is built with C++.
The FakeIt page says it is supported for both C++11 & C++ projects but when I build my application with the header from the library it complains about not able to resolve the C++11 symbols.
gtest/include/fakeit.hpp:28:25: error: unordered_set: No such file or directory
gtest/include/fakeit.hpp:29:17: error: tuple: No such file or directory
gtest/include/fakeit.hpp:32:18: error: atomic: No such file or directory
I'm new to C++, so would appreciate any pointers here thanks.

C++11 support is often not enabled by default. Compile your program with the -std=c++11 argument. For example:
g++ -std=c++11 -I/path/to/libray file.cpp
Also, do make sure your compiler actually supports C++11, it should complain if it doesn't understand -std=c++11. Here is a list of C++11 features supported by various g++ versions.

Related

MinGW standard library missing any.h?

I recently downloaded mingw from http://www.mingw.org/ and installed its c++ compiler and dependencies, which include installing standard library headers. I have also successfully compiled a hello world program, compilation is fine, and common old headers are there and work fine (such as string.h).
However, when I attempted to #include <any>, it threw an error that any.h does not exist. And sure enough, when I look in mingw\include\, there is no any.h (and I see other things missing, such as variant.h).
I've looked through the mingw package manager, and I have the standard library stuff installed, and there's nothing else relevant to install. Does minGW support C++17? If so, how can I get these newer header files? It seems like this should be something really obvious.
You need mingw-w64, which provides more recent GCC versions:
http://mingw-w64.org
You can find a 7.2.0 download here:
http://mingw-w64.org/doku.php/download/mingw-builds
The any feature requires C++17 support, so if your compiler implementation actually does support it, you probably want to specify it on the command line like this:
g++ -std=c++17 a.cpp
Of course, this requires a modern C++ compiler, like that you can get from nuwen.net.

GNU C++: unique_ptr.h no such file or directory

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.

Enabling the -std=c++0x or -std=gnu++0x compiler options

I try to compile a particular source code written in C++, and I do not get an executable file. Instead, I get the following message from the terminal:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/array:35,
from cpptesting.cpp:6:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
What does this message mean, and how can I fix the system? I have tried entering the directory 'include', but could find no 'c++' option. Does anyone have advice?
How do you compile it? if you are using console command like gcc .\cpptesting.cpp, you should just add an option to it:
gcc -std=gnu++0x .\cpptesting.cpp
If you are compiling more complex program with make, check a makefile.
By the way, you are using pretty old gcc version, in the more recent versions this standard is enabled by default(IIRC).

clang++, boost::spirit and c++11

I'm using clang++ (clang-421.0.60), packaged with Xcode 4.6, and came across an issue with boost::spirit. If I compile without any flags, everything compile fine. If I compile with '-std=c++11', then I get the following error (on including of "boost/spirit/include/qi.hpp"):
In file included from test_spirit11.cpp:1:
In file included from /usr/local/include/boost/spirit/include/qi.hpp:16:
In file included from /usr/local/include/boost/spirit/home/qi.hpp:14:
In file included from /usr/local/include/boost/spirit/home/qi/action.hpp:14:
In file included from /usr/local/include/boost/spirit/home/qi/action/action.hpp:21:
/usr/local/include/boost/spirit/home/support/action_dispatch.hpp:21:10: fatal error:
'type_traits' file not found
#include <type_traits>
The problem is that the default library used (stdlibc++) has type_traits defined as 'tr1/type_traits', whereas boost::spirit expects just 'type_traits'. I can of course fix this problem by doing:
clang++ -std=c++11 -stdlib=libc++ <...>
While I would love to use libc++, the practicality of doing so is difficult (many libraries still use and depend on stdlibc++). Thus, I am forced to not use libc++.
Does anyone have any suggestions on how to deal with this? I really wish that either more library maintainers support libc++ or that Apple provided a newer version of stdlibc++. It's been a major frustration to have access to new c++11 features, but not be able to fully use them due to lack of library support.
The problem is that the default library used (stdlibc++)
It's called libstdc++
has type_traits defined as 'tr1/type_traits', whereas boost::spirit expects just 'type_traits'.
<tr1/type_traits> is not the same thing, it's a different header entirely. boost::spirit wants the C++11 header <type_traits> which is a different header (though they do contain some similar functionality, in different namespaces.)
The problem is probably that you're using the libstdc++ that comes with Apple's ancient version of GCC (4.2) which doesn't support C++11.
If you want to use C++11 you either need to use clang with libc++ or install a newer GCC to get a newer libstdc++. Apple won't provide a newer GCC for licensing reasons, but you can install it yourself and tell Xcode how to find the headers and libs.
If you don't want to use C++11 features in boost you can disable it.
Edit boost clang.hpp to manage features.
For example to disable type_traits file not found error you can add to the end:
#define BOOST_NO_VARIADIC_TEMPLATES

K&R style function definition compile using g++

When compiling a c file that uses old style function definition like
int foo(a)
int a;
{
...
}
g++ will give and error: ‘a’ was not declared in this scope.
gcc can parse this.
Is there a way to let g++ recognize this?
This comes up as an issue to me because I'm compiling a mix of c and c++ files.
A related question is what's the standard practice
of building this type of mixed source? Running g++ on all files or only the cc files? The former is convenient but keeps getting me some trouble because of the inconsistencies between c and c++ specification(for example, char[4]="four";)
Is there a way to let g++ recognize this?
This syntax is not supported in C++.
Running g++ on all files or only the cc files?
See e.g. Compiling C++ programs from the GCC docs:
C++ source files conventionally use one of the suffixes .C', .cc, .cpp, .CPP, .c++, .cp, or .cxx; C++ header files often use .hh, .hpp, .H, or (for shared template code) .tcc; and preprocessed C++ files use the suffix .ii. GCC recognizes files with these names and compiles them as C++ programs even if you call the compiler the same way as for compiling C programs (usually with the name gcc).
However, the use of gcc does not add the C++ library. g++ is a program that calls GCC and treats .c, .h and .i files as C++ source files instead of C source files unless -x is used, and automatically specifies linking against the C++ library. This program is also useful when precompiling a C header file with a .h extension for use in C++ compilations.
So two possibilities:
Run gcc on C files, and g++ on C++ files.
Run gcc on all files.
In both cases you will need to link with g++ (or gcc -lstdc++).
Oli is correct: C++ doesn't support old-style function definitions.
Compile C with a C compiler (such as gcc).
Compile C++ with a C++ compiler (such as g++).
They're two different (though closely related) languages. You can use C++'s extern "C" feature to invoke C code from C++ and vice versa; see section 32 of the C++ FAQ Lite for more information.
If you are going to compile both C and C++, you are better off compiling always with gcc (it will choose the language based on the file extension) than g++ (will always compile as C++). You will need to change your linker options to include C++ standard library (and -lm if you use it) as those are automatically added by g++ but not gcc.
Alternatively, a better option is to call the g++ for C++ and gcc for C files. That should not be too hard to manage by configuring the build system.