Here is what I'm trying to do.
I have a folder called Agui which is the lib's folder. In that folder there is another folder called Widgets. I want a file from Agui/Widgets to #include base.h from Agui folder. How should I do this so that it remains cross platform? Should I simply include <Agui/base.h> ?
Thanks
#include "../base.h". And yes, that is portable.
You can use:
#include "../base.h"
From your Agui/Widgets folder. It should work. It should be cross platform.
Better is
#include "Agui/base.h"
or
#include "../base.h"
depending of whether your library root or current folder are added to the include search path.
Angle brackets are reserved for system libraries (although one can actually use any kind of them).
Its better to have the path setup in $PATH and in $LD_LIBRARY_PATH. By doing the above, you can just refer to the header file :
#include <base.h>
This will help to configure/run in any platform
Related
I'm trying to make a cross-platforms crypto library in C++ at https://github.com/haithngn/cryptor something like https://github.com/MailCore/mailcore2
The Structure is:
Can I make any header files can be include in the statements like this:
#include <Cryptor/MD5Encryptor.h>
I can include these header directly from absolutely file path
../core/CryptorCore.h
But these format will make the source code cannot build succeed in an XCode Project.
I tried to simulate the MailCore2 but that's very difficult.
Hope you can suggest me any solution or do a favor PR on my Repository.
Thanks,
You need to have a proper hierarchy. First, no, you can't have
#include <Cryptor/MD5Encryptor.h>
with your current setup, not while building the library, and not without flattening the hierarchy when installing your files (which CMake can do).
What you can do is:
#include <Cryptor/core/abstract/MD5Encryptor.h>
if you add your project inside a Cryptor folder instead of being at the root of your project.
I would advise you to create a Cryptor.cmake file that would allow people to pick up your library once installed, so that they don't have to know where the library includes are or what the libraries name is.
It should not be necessary to point to every single header file. Just add all directories containing these header files with include_directories(PATH_TO_HEADERS).
For the include of the header file src/core/CryptorCore.h with
#include "CryptorCore.h"
you have to point to
include_directories(${PROJECT_DIR}/core/)
I'm developing in VS2010 and looking to add code to an already existing project.
This is a Win32/MFC by the way.
And I couldn't help but notice that in class MyClass (in this case MyClass was an extension of the CDialog Class) the following was included at the top of the cpp file:
#include "MyClass.h"
#include ".\myclass.h"
I noticed that the second include was typed in without capitalization, but I couldn't quite figure out why?
"MyClass.h"
will be searched on INCLUDE_DIR path, which is defined in your project settings.
" ./myclass.h" will be searched in the same directory than the current file.
Windows files names are not case-sensitive so if your working dir is in your include path, these lines are pointing to the same file.
This redundancy is probably a way for VS to ensure the file will be included at least once...
Edit: thanks Arne Vogel, I was tired and wrote false things.
Your compiler will look for your header files only il the file name is like #include <file.h>
But I guess that the redundancy is to be compliant with all file systems.
.\ says to look in the current directory. I'm guessing with the include guards in that header, that wouldn't be a problem.
#include "MyClass.h" is from environment path, while #include ".\myclass.h" from current path.
most of the time, "MyClass.h" in the inc directory under your project, but you MyClass.cpp in other path.
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.
For example, if I had a file called foo.h, can I always just include it by doing:
#include "foo.h"
or do I sometimes have to do something like:
#include "bar/foobar/foo.h"
EDIT - are they simply used to make the compile time shorter by limiting the search for the file?
Basically, you can pass include paths as options to the C++ compiler, but it won't look for the file recursively. If you pass in the path /opt/include and do "#include "foo.h", it will _ only_ find /opt/include/foo.h, not /opt/include/dummy/foo.h.
In other words, either you pass every possible include path on the command line, or pass the root in and "navigate" by using the #include "dummy/foo.h"
Edit: #MatthieuM. made another good point below, #include "mylibrary/api.h"makes it much clearer which include file you're using than just #include "api.h", especially if you're using multiple libraries.
The compiler isn't going to recursively search your source directory. If you want to use #include "foo.h", you'll need to compile with -Ibar/foobar to tell the compiler it should look in bar/foobar for header files.
Otherwise, you'll have to use the full (relative) path. I tend to prefer this over -I, because it makes the source more independent from compiler flags (which you'll appreciate when changing between build systems).
There may be cases where there are multiple header files with the same name - in this case, a path helps to disambiguate.
I think it depends of your project settings, for example you have section like "Additional Include Directories" in Visual C++ so IDE will also search files in these directories.
The first statement #include "foo.h" will search for foo.h in the current working directory or in the directories mentioned under additional include directories.
If your header file is in some other path you need to explicitly mention it.
I'm developing a library that is to be used (after compiled and installed) by another developer. All my includes are like this:
#include "../exception/CException.h"
All goes well but when I install the library and use it in another program with #include <> that include a file that have #include "../exception/CException.h" the last file is not found. Why?
Any help to improve include usage?
The problem with a relative path is that we don't know for sure what it is relative to. Different compilers have different ways of doing this.
You should rather use
#include "yourlib/exception/CException.h"
similar to Boost.
If you install this as a subdirectory yourlib in /usr/local the compiler should be able to find that.
You'll need to distribute ../exception/CException.h with your library. If it's really part of your library putting it in a subdirectory rather than a sibling would be preferable.