If I simply include a file by writing
#include "blah.h"
where exactly does the compiler search for this file? I understand that there are limitations.
What happens if the file is not in the same folder, but much deeper in the structure, how do I tell the compiler to look there? equally if it is above the file in the directory? or maybe deeper in a different branch?
Essentially I don't have a grasp of how you navigate around the structure. I've seen some includes that look something like:
#include ".././foo/whatever/blah.h"
what do the dots mean? they go back up but do different numbers mean different things?
Also is this based on the structure of the files on the computer or their structure in the solution explorer?
Thanks very much for the help on this one, I understand this is a bit of a basic question - just one of those things I never learned.
From the visual studio documentation on #include
The preprocessor searches for include files in the following order:
In the same directory as the file that contains the #include statement.
In the directories of any previously opened include files in the reverse order in which they were opened. The search starts from the directory of the include file that was opened last and continues through the directory of the include file that was opened first.
Along the path specified by each /I compiler option.
Along the paths specified by the INCLUDE environment variable.
You can change the paths passed to the compiler via /I options in the visual studio project settings (for project specific paths) and in the visual studio options for global paths.
2 dots in a path move you up a directory, one dot refers to the current directory. Any other number of dots would not be valid. So your example path of .././foo/whatever/blah.h essentially means "move up one level, look in a folder foo, then look in a folder whatever". The single dot in this case doesn't really do anything.
This navigation is based on the file structure, not the structure in solution explorer
When you write #include "a.h" in a.cpp, then preprocessor searches a.h in the same directory where a.cpp is. If this search is not supported, or if the search fails, then preprocessor searches a sequence of implementation-defined places for this a.h.
"what do the dots mean?"
Lets say you have file with this fullpath: C:\myDir\myProjects\a\a.cpp:
. = C:\myDir\myProjects\a
.. = C:\myDir\myProjects
You should also take a look at What is the difference between #include <filename> and #include "filename"?
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.
I am trying to include a few libraries in code blocks, however when I add the path of the .h files to the search directory (example C:\Qt\5.1.1\mingw48_32\include\QtNetwork), it only seems to identify the ones in the main file and I think that is due to the fact that in the main file they are included as such (for example) #include "qtcpsocket.h", whereas in the .h file they are included as (for example) #include <QtNetwork/qabstractsocket.h>.
Apart from the fact that one includes the folder in which it is located, what is the major difference? Why it may not work? and what do it need to do to change it?
one more thing I'm sure the files are in the folder.
Here are a few code snippets if this helps
location of file
error
If your source code contains, e.g.
#include <QtNetwork/qabstractsocket.h>
then you are requesting the preprocessor to find and include a file called
QtNetwork/qabstractsocket.h
(or, QtNetwork\qabstractsocket.h, if you're on Windows, as you are)
in one of its search directories.
And if you have specified compiler search directories:
C:\Qt\5.5.1\mingw48_32\include\QtNetwork
C:\Qt\5.5.1\mingw48_32\include\QtCore
then the preprocessor will search the first directory for:
C:\Qt\5.5.1\mingw48_32\include\QtNetwork\QtNetwork\qabstractsocket.h
which does not exist. And it will search the second directory for:
C:\Qt\5.5.1\mingw48_32\include\QtCore\QtNetwork\qabstractsocket.h
which does not exist either.
The usual way would be to specify the compiler search directory:
C:\Qt\5.5.1\mingw48_32\include
and in your code write your #include <...> directives like:
#include <QtNetwork/...>
#include <QtCore/...>
I'm trying to write a program using flex++, however everytime I try to compile I receive the error message:
FlexLexer.h: No such file or directory
However that header is found on the include folder of flex. I don't have problems compiling lex programs for c, however for c++ with flex++ I can't seem to find a way.
I already downloaded flex various times and I don't know if there is a problem with my OS or something like that. My OS is Windows 10.
Thank you
Including should be pretty straightforward once you understand how it works.
Let's look at some different ways you can include a file:
#include "FlexLexer.h"
The quotes tell the compiler to look for the file FlexLexer.h in the same folder as the file being compiled. That is it, it won't look anywhere else.
Now if we change the quotes to brackets:
#include <FlexLexer.h>
This tells the compiler to look for FlexLexer.h in the same folder first, but then if it isn't found it will go through the list of include paths looking for it there, too.
Assuming you are using VisualStudio, there is both a system list of include paths (see Tools > Options > Projects and Solutions > VC++ Directories) and a project list of include paths (right click on the Project in the Solution Explorer, Properties > VC++ Directories). Both of these lists are traversed.
Finally, you can also add subdirectory qualifies to the include, e.g.:
#include "Win\FlexLexer.h"
or
#include <Win\FlexLexer.h>
As you might guess, it looks for the path under either the current directory in the both examples and also under the include path list in the later example. Regardless, the first time the file is found the search will stop and the compiler will use it. So be careful if there are headers will duplicate names in different libraries!
I want to add an #include directive to my A.cpp file, and the header file B.h is in the folder two layers up (for example, if the source file is in *E:\A\B\C\D\E\F\G\H*, the header file is in *E:\A\B\C\F*, of course, the names will be much longer than this), so I typed this confusing statement in Visual Studio 2010:
#include"../../
And the Intellisense feature in VS 10 showed up a list of the files, and B.h is in it! I don't know if this statement is correct, but I think there is something wrong with this. Could any of you tell me whether this is wrong or correct? And could you give me a better solution for this?
Thank you very much.
Why wouldn't it work? Have you ever done cd ../../mydir and checked what that does? It's the equivalent of that. .. and . point to a special directory in both Windows and Linux. . is the current directory while .. is the previous directory. So ../../file.h would go two directories back to find the file you're looking for. After all, the #include "..." statement works with the relative path the file is located in. Usually when writing libraries and you have a main detail subdirectory you would try to access it via #include "../detail/myfile.hpp", while other libraries such as boost opt for #include <boost/config/myfile.hpp>
I think it is best to include the "-I <INCLUDE_DIR>" parameter to your build and just #include the header without the directory listed. The is where you are telling the compiler and linker to look for your header files.
..\ moves you up one directory, so ..\..\ will move you up two directories. I suppose this is fine if you can assume the script location will never change. If, however, you moved the script to a different drive you would be in trouble. It might be better to include E:\A\B\C\D\E\F\B.h instead to future proof yourself.
I come from a Java/AS3/Javascript background where all of my classes are organized into packages that help denote their functionality.
In starting a C++ project I sought to mimic this file system structure in mostly the same way but I've been running into issues with the includes.
Currently I have an src directory with the main.cpp file inside it. Then I have some root directories and with other files inside. Here's an example:
src
->main.cpp
->window
---->Window.h
---->Window.cpp
main.cpp includes Window.h with the statement #include "Window.h" and everything builds just fine. But if i restart Visual Studio, it complains that it can't find "Window.h".
In looking a open source projects, I've seen some that just have all the source files in one directory with no nesting for easy includes I suppose. Some have the headers and cpp files separated.
What is the correct way (or at least a way that will cause less headaches) to organize a large-ish C++ project on the file system?
Thanks!
Breaking it out like you've tried to do is reasonable and easy enough to accomplish.
You just need to set your project's include paths. From Visual Studio, right click on the project name and click "Properties". From there, in the tree control on the left hand side, expand "C/C++", and then select "General" in the tree. The first option on the right hand side should then be "Additional Include Directories".
There you have several options:
You can specify specific include directories (separated by semicolons). For instance, if you had folders "Window" and "Printing" you could put in:
..\Window;..\Printing
Which would allow you to include the files from window and printing easily, like this:
#include <Window.h> // from src/window
#include <Printing.h> // from src/printing
The above approach has some drawbacks, as you can easily collide with names from other libraries you may be using, making the include ORDER very important.
A better approach (in my opinion) is to add the following as an include path:
..\
This will make it search the parent directory when looking for includes. This allows you to be more verbose in your include paths, like this:
#include <Window/Window.h> // it's more clear where these are coming from
#include <Printing/Printing.h> // and much less likely to collide with other library
// header files
It makes sense to follow the Java example and arrange source files by C++ namespace. Create sub-folders under your /src directory that correspond to the namespaces.