I have a c++ project where the build process is organized by cmakelist， the compile stuck at a point and prompt that g++ cannot find json/json.h, I check my standard header path(/usr/include) which indeed has this hearder file. after struggle for a while I found This project use header file from its own thirdparty directory(not /usr/include) and the include_directory path was incorrectly set by me!! This upset me How can it be realized since #include <> should firstly search standard header file path(/usr/include) !!??
This documentation
https://en.cppreference.com/w/c/preprocessor/include
Says about including with ""
"Typical implementations first search the directory where the current file resides and, only if the file is not found, search the standard include directories"
I'm not certain I understand your question very well but,
if json/json.h is present in your local directories,
may be should you include this header-file with ""?
Related
I'm kind of new to programming so please go easy on me. Anyways, I know about including header files that you, yourself, have defined. For example:
#include "yourHeader.h"
I'm trying to use FLTK for its GUI options, however, many of its header files include other header files using an include like this:
#include <FL/Blah.h>
instead of this:
#include "FL/Blah.h"
I would have to go every header file that has the include in angle brackets and change them to quotation marks for them to work. I am currently working in CodeBlocks right now, if that matters. Is there any way to include the header files using angle brackets instead of quotation marks, or am I stuck with having to go into the header files themselves and manually swapping them all out?
Generally， the header file from
#include "headerfile"
will searched in the current source path. If the search fails, it is reprocessed as if
#include <header file>
does.
Your FLTK library is using include like the following?
#include <FL/Blah.h>
The FL's parent path should be in the predefined INCLUDE path. You may edit you Makefile or project settings.
You can add the folder which contains all your headers to your include path while compiling.
How to add a default include path for GCC in Linux?
Some background
Ok there are two set of include search path.
The user include path:
This is usually only the current directory (also known as ".").
Note: It may be others but for simplicity lets just use "." in the examples below.
Then there is the system include path:
This is usually a few places in your machines (could be /usr/include and /usr/local/include).
Note: It may be others but for simplicity lets just assume these in the examples below.
How it usually works.
There are caveats and not all compilers work exactly the same. But the following are a good rules of thumb.
When you include a file using quotes "".
#include "yourHeader.h"
It will search for this file in all the directories specified in the "user include path". If it fails to find them there it will then look in all the directories specified by the "system include path". So your compiler will search for the following files:
./yourHeader.h
/usr/include/yourHeader.h
/usr/local/include/yourHeader.h
It will use the first one it finds.
When you use the <> in the include:
#include <FL/Blah.h>
It will search for the files in the "system include path" first. Then depending on your compiler may optionally search the "user include path" (but lets assume not for now).
So in this case it will search for the files:
/usr/include/FL/Blah.h
/usr/local/include/FL/Blah.h
It will use the first one it finds.
Modifying the Default
So these are the default paths that will be searched for a file. But your compiler will allow you to add extra paths to both of these search paths (usually). It depends on your compiler how to add search paths.
For gcc (and probably clang) it uses -I and -isystem (and probably more)
Expectations.
When you see <> in the include header it usually means this is an already installed library that you are looking for. So your code assumes that the FLTK library has already been installed on your machine.
When you see "" in the include header you should assume that it is a local file that belongs to the project.
#include<apis/api1/api.h>
throws No such file or directory
i even tried moving api.h and api.cc to the main project directory and using
#include<api.h>
does the same thing even though it is in the exact same directory that the other classes use
i tried adding /apis/api1 to the compiler search path
that just crashes the compiler can someone tell me what to type into the compilers compilation line
#include <api.h>
is the way you include a system header. (That is, the header for a library installed on your system.) It does not search in the directory of the source file or in directories specified in -I command line arguments.
#include "api.h"
is the way you include your own headers. (But it will also search library header locations if it doesn't find the header locally.)
I'm trying to build a project I have done for Windows, Visual Studio under OSX using Xcode 6.1.1.
I'm running into an issue where in a file that needs to include #include <string.h>. However, in the same folder as the file that does this there is also a file that is named string.h.
Under my Visual Studio project this still resolves file, the system paths are searched first.
In the Xcode project I have made sure to set up my own paths under "User Header Search Paths" - Xcode expand to the correct path. I also set "Always Search User Paths" to No - which according to the docs says that the system paths should be searched first:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3-SW110
But yet the #include <string.h> seem to be treated as #include "string.h" for some reason.
The config is defined in the project and I've made sure the targets doesn't override this.
Is this some Xcode/OSX thing where system includes <> search the path of the including file first?
My local string.h file is located at ruby/api/string.h relative to the include path in my User Header Search Path.
Results of https://gist.github.com/thomthom/034b539bede38dd68261:
https://gist.github.com/thomthom/034b539bede38dd68261
The paths searched to satisfy an #include directive and the order in which they are searched are implementation defined. That includes whether any user-specified include paths (if even supported) are searched before, after, or instead of any default paths.
That's the case for both forms of #include directive. In particular, although it is common for implementations to perform some kind of relative search to find a file specified using the double-quoted include syntax, C does not require that. It requires only that if the implementation-defined mechanism used for resolving double-quoted includes fails, the compiler must fall back on the implementation-defined method used for resolving angle-bracketed includes.
Moreover, C specifies behavior only for the case that the given header name uniquely identifies a file to include. Depending on how one construes "uniquely", one might claim that C does not define any behavior at all in the situation you describe, on the basis that you have not uniquely identified the header you want to include. That's a bit wild, though -- I think it's better to interpret "uniquely" in light of the implementation-defined method for locating headers.
Your best bet is to avoid header names that collide with standard header names. One version of that would be to put them in a subdirectory that will lend its name as a prefix. For example, put string.h in src/myapp/, and include it as
#include "myapp/string.h"
To make that as safe as possible, ensure that directory src/ is in the include search path.
Upon viewing your gist I noticed a discrepancy from your screenshot:
HEADER_SEARCH_PATHS = /Users/thomas/SourceTree/SUbD/SUbD/../ThirdParty/include/ruby/mac /Users/thomas/SourceTree/SUbD/SUbD/../ThirdParty/include/ruby/mac/universal-darwin12.5.0
This should be:
HEADER_SEARCH_PATHS = /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
Have same issue with file <assert.h> in Xcode 13.4.
I fixed by set "No" for build setting "Search Paths" > "Use Header Maps".
Maybe help someone.
This question already has answers here:
What is the difference between #include <filename> and #include "filename"?
(30 answers)
Closed 8 years ago.
I am new to C++.
What is the difference between including the c++ header files using "" and <>
I am trying to use some of the header files form an open source library. All header files in that library are included using <>. Now when I do the same in my header file, its failing at compile time.
<> looks firstly in the header path for the header file whereas "" looks firstly in the current directory of the file for the header.
The distinction is very largely implementation defined; the "..." form
should look first in the place where the file which includes it is
situated; the <...> no. Beyond that, both look in an implementation
defined list of places, with the additional requirement that if the
compiler doesn't find a "..." form in any of the expected places, it
reprocesses the include as if it were a <...> form.
In practice, all of the compilers I know build a list of places using
the -I or /I options, followed by a number of "standard" and
compiler defined places. This list is for <...>; "..." is searched
in the same directory as the including file, then treated as a <...>.
(Some compilers, at least, also have options to add to the list for
"...".)
I'm not sure what's happening with regards to the library. Normally,
when using a third party library, you have to add one or more -I or
/I options to tell the compiler where to find its headers. Once
you've done that, both your code and the library code should find all of
the necessary headers. The one case I can think of where an include
might work in a library header, and not in your own headers, is a
"..." style include in a library header which was included from
another library header, using a path specifier, e.g.:
LibraryFile1.hpp:
#include "Subdir/LibraryFile2.hpp"
LibraryFile2.hpp:
#include "LibraryFile3.hpp"
You will have told the compiler to look for the headers (using a -I
option) in something like LibraryRoot/include, which is where
LibraryFile1.hpp is located; LibraryFile2.hpp is relative to this
location, and in LibraryFile2.hpp, the compiler finds
LibraryFile3.hpp because it is in the same directory as the file which
includes it. If you try to include LibraryFile3.hpp directly,
however, the compiler won't find it.
File includes between <> are looked for in your compiler's path, whereas "" is looking relatively to your current directory (or absolute if you specify a path that starts with / or c:\ but this is not recommended)
On Unix systems, by default the path contains /usr/include. This path may be completed by adding -Isome_directory for it to search in it.
For example, if you have your file test.c and you want to include include/test.h, you have different choices:
Write #include "include/test.h", which will look relatively from the directory of the compiled file.
Write #include <test.h>, but this time you will need to specify -Iinclude to the compiler to add the ./include directory to the compiler's path.
Note, however, that some compilers accept the "" notation for lookups in the path, but that always confused me and is a bad thing to do.
The quotes mean include from local folder and the <> mean to include from another directory specified using a flag to g++ or MSVC or whatever compiler you are using or system headers.
<> looks in the default directory for include files, "" looks in the current directory and than in the default directory
This question is a duplicate of Question 21593. None of the above answers above are totally correct. Like many programmers, I have used the informal convention of using the "myApp.hpp" form for application specific files, and the form for library and compiler system files, i.e. files specified in /I and the INCLUDE environment variable. However, the C standard states that the search order is implementation specific.
Here's the msdn explanation copied here for your convenience).
Quoted form
The preprocessor searches for include files in this order:
1. In the same directory as the file that contains the #include statement.
2. In the directories of the currently opened include files, in the reverse order in which
they were opened. The search begins in the directory of the parent include file and
continues upward through the directories of any grandparent include files.
3. Along the path that's specified by each /I compiler option.
4. Along the paths that are specified by the INCLUDE environment variable.
Angle-bracket form
The preprocessor searches for include files in this order:
1. Along the path that's specified by each /I compiler option.
2. When compiling occurs on the command line, along the paths that are specified by the INCLUDE
environment variable.
Including a file using <> will tell the compiler to look for those files in environment-defined inclusion folders. Those folders can be standard system folders, or defined by your Makefile if you use one, etc. Using "", the compiler will look for inclusion files only in the source file's path.
So you can use "" and use absolute paths or the path which is relative to the source file you try to include in, or you can use <> after defining your inclusion folders, and just specify the name of the header file to include.
IMHO, the second option is better, especially if you use a lot of headers, or multiple libraries, etc...
To define inclusion folders at compilation time : gcc -I ... (man gcc!)
I'm using VS2010 (downloaded via dreamspark) and although I can open the #include file by right clicking on it and pressing on Open Document, it complains "Error can not open source file "..."" which seems rather absurd. I'm using Qwt with Qt this time around and I'm specifically having the problem for:
#include <qwt_counter.h>
#include <qwt_plot.h>
(And I am using the "<>"); not sure how to make those appear properly in the code above.
Thanks in advance.
As Neil indicated, try using quotes instead of the <> characters around the filename. When using the quotes, MSVC will look in the same directory as the file the #include is in for the specified file, then if it's not found there will look in the directories specified by the include path. When the filename is surrounded by <> characters, the current file's directory isn't looked at - the compiler goes right to the include path.
See http://msdn.microsoft.com/en-us/library/36k2cdd4.aspx for details.
Note that this is an implementation dependent behavior - it might not apply to other compilers.
If that doesn't help, make sure that your include path contains the directory that the file is located in by setting the "Include Directories" property appropriately:
http://msdn.microsoft.com/en-us/library/t9az1d21.aspx
Finally, you might be using a makefile project (I'm not sure how common it is for Qt projects to continue to use qmake when built from VS) , in which case you'll need to perform whatever configuration is necessary in the make file(s) or parameters passed on the command line that invokes the makefiles.
Is the path where these files are located either the same as that of this source file, or included in the "additional include directories" in your project settings?
Project -> properties -> c/c++ section -> additional include directories.
If they are located in a subdirectory of the source file you're editing or of one of the additional include directories (I think) you can also include them with:
#include <path_to_file_1/qwt_counter.h>
#include <path_to_file_2/qwt_plot.h>
[edit]
or of course what neil says
[/edit]
It turned out there was a circular linking happening and I had all my code in a .h file. I split it up and added the corresponding .cpp file, now everything works fine.