I've recently started watching STanford's cs106B lectures on youtube, and I've downloaded their "Stanford C++ Libraries" that they've made. I've right-clicked my project, and added the whole folder (named "cs106lib-0.3.1") to the "Include directories" and "Include Headers" sections" but when I import one of the headers "vector.h" and create an object using it it says "unable to resolve identifier vector", and the compiler says the folder doesn't exist, although it's definitely on my desktop. Sorry, if this question has been asked then I can't find it, but I have been stuck looking for the past day.
Don't mix include directories and -headers.
Include directories: Adds directories where your header files are
Include headers: Adds single header files
Also make sure your paths are ok. Let's assume a structure like this:
cs106lib-0.3.1
|
+-- include
| |
| +-- Example1.h
| |
| +-- subdir/Example2.h
|
+-- ...
In this case you have add the directory cs106lib-0.3.1/include to include directories.
Now you can use it like this:
#include "Example1.h"
#include "subdir/Example2.h"
// ...
Also don't forget to add the binaries (if you have) to linker flags.
TIP: Use the code completion to see where you are; eg. type #include "../" <Ctrl+Space> to see files and directories available for to include.
Related
I am new in programming I am using vscode in windows and compiling via Mingw 64. I am requesting an answer to this question after tried of trying for days. I googled it many times. here is how my project tree looks. please help me include and link libA to libB and common.h to all cpp files and libA and libB to to main.cpp. Please answer.
project
|---lib
| |---libA
| | |---header1.h
| | |---header1.cpp
| |
| |---libB
| |---header2.h
| |---header2.cpp
|---common
| |---common.h
| |---common.cpp
|---main.cpp
From VSCode, you can right click on the headers and select Copy Path. That should work when including headers from anywhere on your computer.
As for the .cpp files, you could use relative paths to the directory you're compiling in, when compiling and linking the files, or use the -I option when compiling with g++.
This might help.
You should use the relative path in #include.
For example to import header1 use -#include "./lib/header1.h"
and to import common use #include "./common/common.h"
I have a project structured in this way:
project
|\_subdir
| | Some .cxx files
| | some .h files (included with #include "foo.h"
| \_subdir
| | Some .h files (included with #include <subdir/foo.h>)
\_subdir2
| some .cxx files
| some .h files (included with #include "foo.h"
\_subdir2
| Some .h files (included with #include <subdir2/foo.h>)
I need to do a few things here:
The subdir/subdir directories should be publicly available for use in programs that use this library with #include <subdir/foo.h>.
The subdir directories should produce their own statically linked libraries so that I can run tests making sure that the dependency relationships between the different subdir directories are maintained.
The whole thing should produce either a shared or static library that has everything in all the subdir directories and can be linked to by programs using this library.
Currently I have a build system that I've made using autotools (but not automake) plus some custom made perl scripts that process the dependency output from the -M flags and create custom makefiles that express dependency information. Additionally, they create an include directory that's a linkfarm so everybody can use #include <subdir/foo.h> and just -I the linkfarm directory.
I want to convert this to CMake, but I'm at a loss as to how to handle the subdir structure and includes. I can re-arrange the directory structure somewhat if absolutely necessary, but I would very much like to preserve the pseudo-independence of the various subdir directories, partly because it's very important to me to be able to make sure the sub-libraries have a specific dependency relationship as a way to maintain modularity and cleanliness.
How would I do this in CMake? Do I have move the subdir/subdir directories?
Because it looks like if I add the subdir directories as a public include, then things will go really awry as people will see the private .h files at the subdir level as well as being able to include the .cxx files that are in them. Even worse, they will see them as top-level includes (i.e. #include <bar.cxx> where bar.cxx is a private implementation file who's object code should already be in a library).
But if add subdir/subdir as an include directory, the .h files won't appear in subdirectories like they should (i.e. #include <subdir/public.h> won't work, instead I'll have to use #include <public.h> which isn't my intent at all).
If you bother about users of your library, they will see installed files, not ones in the source/build directories. If you don't install private headers (from subdir/), a user won't see them.
But if you do not intend to install library, then you may separate public and private include trees. E.g. each project may have private headers directly in its source directory, and public headers under its include/ subdirectory:
project
|\_subdir
| | Some .cxx files
| | Private .h files (included with #include "foo.h")
| \_include (public include directory)
| \_subdir
| | Public .h files (included with #include <subdir/foo.h>)
\_subdir2
| some .cxx files
| Private .h files (included with #include "foo.h")
\_include (public include directory)
\_subdir2
| Public .h files (included with #include <subdir2/foo.h>)
I started coding in C++ few days ago. I am using windows as my OS for writing code. I have been keeping all of my "well-written" codes in a single location. Now, I am working on a project that requires the use of those codes. So, I planned to include those files that I require as header files in my project. However, to make my project "self-contained", I created shortcuts of those folders that I require and kept them in the source folder of my new project and decided to use relative paths to the shortcuts in the "include" statements in my project.
However, I am getting an error. Is there any way to use relative (or, in general, absolute) paths to shortcuts in the include statements of C++ in windows?
Thanks.
It really depends on how you include the header files.
If you include with double-quotes, like e.g.
#include "some_header_file.h"
Then the relative path is from the current files location.
If you include using angle-brackets, like e.g.
#include <some_header_file.h>
Then the relative path is based on the system include paths.
You can always add a path to the system include path. How to do it depend on your environment and compiler. If you're using Visual Studio you go into the project properties dialog, and in the "C/C++" / "General" tab there is a field called "Additional Include Directories" where you can add directories. (This is for VS 2015, might be a little different on other versions.)
Regarding double quotes inclusion. Lets say your project hierarchy looks like this (on disk!):
Project
|-- Include
|-- Source
| `-- MoreSource
`-- Other
In Project/Source you have your source files, and if one of them want to include a header file from Project/Include, then it will look something like
#include "../Include/header.h"
Now if you have a source file in Project/Source/MoreSource that want to include the same header file it will be
#include "../../Include/header.h"
It could be useful to add the Project/Include directory to the system header search path. You can still use double-quotes to include the files, since if they are not found then the preprocessor will search the system paths as well, but you don't need the "full" relative path. If you add Project/Include to the system header path, you could write just
#include "header.h"
Or
#include <header.h>
Be careful though, if you have a header file with the same name as an actual system header file you might have some trouble.
From https://superuser.com/questions/253935/what-is-the-difference-between-symbolic-link-and-shortcut
You can't include folder shortcut since it's a file, not a folder.
You can read the guide to create symbolic link on windows.
I tried to shorten down my question (the Old question can still be found below)
My current directory structure looks like this
C:\users\documents\projects
|
+----- utility
| |
| +----- include (files not shown)
| +----- src
| |
| +----file1.c (and other files not shown)
|
+----- proj1
|
+----- include (files not shown)
+----- src
|
+----- proj_file1.c (and other files not shown)
I can include the .h files from ..\utility\include with #include <file.h> to proj1, if I add this directory as include path to my IDE (in proj1). Is there an aequivalent solution for the ..\utility\src files? I am using LPCXpresso IDE on Windows 7. I suppose there is the same solution on any IDE, so I just want to know how this whatever path (where .c files will be searched, if not found in the .\src directory) is generally called to find it in my project settings.
I try to avoid using libraries (.lib, .dll)
I don't want to copy the .c files in each project (proj1, proj2, ..., projn)
I want to be able to simply edit the .c and .h files and if recompiling proj1 and so on the changes will be applied, as they will for all other projects
Generating an own makefile may be a solution (but shouldn't there be an Option to add a source-file-path in IDEs?)
#include <..\utility\src> is a non-desired solution as changes to the directory will fource to add this line in each single file, where changing a path in the Options are only some clicks.
Thanks in advance and thanks for the answers up to now
Old Version of my question:
Motivation: Imagine, you write a program in C/C++ in some IDE and have .c and .h source code files as usual. In addition you have a helper.c and helper.h file, were you defined some useful, not project related functions (which can be used in several projects). You want to include these files, but don't want to have them were you store your project related source code.
As far as I know .h files can be stored in a separate folder, which is pointed to by the includepath. This path can be set in every IDE. Further it changes the
#include "helper.h"
statement to
#include <helper.h>
If I put the .c files in the same folder and not include them separately, the compiler will not find them. If I include them as well with
#include <helper.c>
a multiple inclusion will lead to multiple function deklaration and therefore to a compiler-error. Only solution may be an
#ifndef helper_c_
//content of helper.c file
#endif
, which is kind of impractical and will always need inclusion of the .h and the .c file. But i only need to have them stored once, with no copies and if i need to change something, it will change in all projects, as they are all pointing to that folder
I also now about library files, where you have an .lib and a .dll file, where the .lib file needs to be pointed at by the library-path and the .dll file needs to be in the same folder as the .exe file afterwards. But that is not what i want.
My Question: Is there a possibility to store the .h and .c file (in my current case there are 10 file-pairs) in a separate folder and point at them via an include path or so? I tried googling around, but I think I am not quite sure what i shall look for.
Thanks for help
EDIT: I forgot to mention: I use Windows 7, and my current IDE is the LPCXpresso-IDE
OK, suppose you have this directory structure:
C:\users\documents\projects
|
+----- utility
| |
| +----- include (files not shown)
| +----- src
| |
| +----file1.c (and other files not shown)
|
+----- proj1
|
+----- include (files not shown)
+----- src
|
+----- proj_file1.c (and other files not shown)
And also assume, that the current directory for compilation is in the proj1/src directory. I see at least three solutions to your question:
if you really want to #include the source files, which I do not recommend doing, just use a relative path to the files i.e.
#include "..\..\utility\src\file1.c"
Now in addition to the issues with including source files, this tends to be very fragile in that if you change the directory structure (or change a name of a directory) everything breaks. You would need to go back into your source and fix every line of code.
As iharob suggested, use a make file to handle this. In this case, you would have a compile line that looked like this (assuming you are using Microsoft's tool change);
cl /I..\..\utility\include ..\..\utility\src\file1.c /o util_file1.o
This causes the result of the compilation to be dropped in the current working directory and the linker will be able to find all the object files and combine them together into one executable. We still are dealing with relative paths here, but all the changes would be in a single file, and by using make variables the changes would be on a single line or two.
If the functions in the utility directory are going to be used in multiple projects, my personal favorite solution is to make a utility project that produces a dynamic library (a dll under windows) and link subsequent projects with that library. You still have to deal with locating where the include files are going to be (maybe a directory at the top level of where all your project folders are?), but to me a library seems cleaner. It also has the added advantage that if you want to modify the code in the utility project, just recompile the library and the rest of you project will 'see' the modifications with out recompilation of them (assuming you do not modify the interface of the library).
Hope this helps,
T
Yes of course there is, depending on what compiler you are using there will be a switch to tell the compiler where to search for headers, for gcc and some others AFAIK, it's -I, so for example suppose that your headers are in the myproject/headers directory, the compiler should be invoked like this
gcc -I myproject/header ${OTHER_OPTIONS} ${SOURCE_OR_OBJECT_FILES} -o ${OUTPUT_FILE}
The usual way to build a project with the .c files in different directories is to use a Makefile and a program that can parse the Makefile and invoke the neecessary commands to build the project.
A word of warning: it is generally not a good idea to #include source (.c) files. The source files are meant for compilation, not inclusion -- including them may result in strange errors (most prominently, apparent re-definitions of a function).
Here is what I would do (for each project that needs the helper code):
Add your utility .c files to the project. Look for Add existing file... or a similar IDE feature; this ensures that your utility source files, i.e. helper.c, get compiled along with your project.
As for the .h file, include it with #include <helper.h>, enabling you to use your utility declarations.
Finally, find a compiler option called Include paths, a.k.a. -I, and set it to the folder that contains helper.h. This is usually found in Project options/settings.
After looking around through all the settings and options I found the following satisfying solution: creating a Link to a source file folder
This answer applies to the LPCXpresso IDE
imagine the folder structure shown in my question
inside the LPCXpresso IDE -> rightclick on the project -> properties
navigate to C/C++ General>Paths and Symbols>Source Loacation
click "Link Folder..."
in the opened dialog tag the checkbox Link to folder in the file system
click Browse... or enter C:\users\documents\projects\utility\src
click OK
click Apply
recompile and be happy :)
I'm working on an existing Visual Studio 12 "Solution" from another team..
In one of its "project"s,, there's a header file that includes a file from another static library projecet..
So Lets say the solution structure looks something like this:
Project A (Static Library Project)
\__ someFile.h
Project B (Static Library Project)
\__ someLibrary.h
In someFile.h,
...
#include "someLibrary.h"
...
and this loads the library successfully.. BUT this is strange because the path to someLibrary.h is NOT SPECIFIED anywhere in Project A's settings!!
I've checked Configuration Properties => VC++ Directories => Include Directories but path to someLibrary.h is NOT specified here..
Since Project A is a static library with NO cpp files (has only header files), It does not have a Configuration Properties => C++ => Additional Include Directory Option at all... (It only has the Librarian option)
And of course someLibrary.h is not in the same directory as someFile.h.
Finally, in Project A's Common Properties, Project B is not referenced either...
So my question is : How the hell does someFile.h know where someLibrary.h is?
How is it including it??
Is there any other places in project settings/etc where additional include directory can be specified..?
UPDATE:
when I right click on the #include statement and click "Open Document 'someLibrary.h'",
I do see a following VS error box:
File 'someLibrary.h' not found in current source file's directory or in build system paths.
Nevertheless,, there is NO build error, and Project A uses someLibrary.h with no problem!!