In a windows MSVC6.0 compiler, if there is a workspace with one project in it, what files would be in the Header Files folder and what files would be in the External Dependencies folder?
I thought those files which are explicitly included (#include <*.h> are to be in the Header Files folder and thsoe which are in turn included by added header files, will be in External Dependencies folder? But doesnt seem to be case.
So what is the difference between the two?
-AD
Header files listed as external dependencies are not analysed and available in the class view tab. Moving a file from external dependencies to header files includes it into the class view.
The folders in the tree view are purely for your convenience (at least in vs200x - I don' remember ever changing hem in vc6).
You can rename them to anything you want and put any files in any folder you want.
I generally create folders based on the parts of the program (ie gui, server, fileIO ) and put the header and cpp files for classes in the same folder so I can quickly find the definition and declaration.
After looking at the structure of header files and #include *.h in the workspace i found following:
1.) Those files which are not explicitly added to the Projects Header Files folder, but are nonetheless included using the #include directive, by different header and source files, are added to the project automatically by MSVC under the folder External Dependencies
But now i have a question, is it better to let MSVC add those header files as External Dependencies or is it better to add it explicitly in the Header Files folder, or is there no difference in the two?
-AD
Related
I have a C++ .h and .cpp file from another project that I want to include into my project.
I don't want to copy the files over into my project since I want any changes to those files be applied to both projects.
I've included the directory of the file's folder in the
Properties->VC++ Directories->Include Directories
I've also included the folder in the
Properties->C/C++ -> General -> Additional Include Directories
The .h files seem to work. If I rename the include to anything other than
#include "myfile.h"
The cpp file gets unknown definitions.
When I compile. The error is
fatal error C1083: Cannot open source file: '..\..\..\..\..\..\my project\myfile.cpp': No such file or directory
If I remove the cpp file from the project. Then I get a long list of unresolved functions.
error LNK2019: unresolved external symbol "public: unsigned long __thiscall myclass::myfunction"
How can I include both the .h and .cpp file into my second project?
For cpp files you can just use right mouse click on project, select "add"->existing item.
Then they should compile with others, when a build initiated.
Slightly more complicated with headers. There is two ways to use #include directive:
with < > and " " braces
When " " braces used, compiler treats path as relative (if not absolute used) to location of cpp file.
When < > braces used, compiler looks for file in something like system include folders. For example - stdlib headers folder and windows.h location folder. Properties entry Additional Include Directories also goes there.
I suggest you to change projects structure and extract shared features from both projects to compile it as static library. Place shared headers in some subfolder inside library project and refer then as
#include "mylibHeaderDir/someheader.h"
In dependent projects, after setting Additional Include Directories you can refer theese includes as
#include <myLibHeaderDir/someheader.h>
This approach will help you in future, as you can reuse that shared module in every project you want.
About how to create and link static library you can read this article http://msdn.microsoft.com/en-us/library/vstudio/ms235627(v=vs.110).aspx Version of visual studio may be differ, but basics are the same.
You can't just pick files like that. There are two reasonable ways to solve it. 1, shared the file by means of a Code Versioning System (e.g. svn/git). 2, compile the the .cpp into a library and link to that library.
If the cpp can be used by multiple projects, it must mean that the code is something common. That means you should compile that code by itself into a library and then share that library. Compiling the same cpp into multiple libraries is likely to result in conflicts later if two such libraries are ever needed to work together.
Try to drag them into your solution?
You can create a new folder in your solution, and drag them all into this folder!
I am using lodepng to produce compressed image files. I have stored the .cpp and .h files (there is only 1 of each) in C:/Program Files/Common Files/lodepng/lodepng, and I want my visual studio project to automatically look in these folders.
I have added C:/Program Files/Common Files/lodepng to my Include Directories, so wherever I have #include <lodepng/lodepng.h> it not picks up that header file, which is nice.
However, when I try to compile I get a linker error (obviously) because I haven't told VS where to look for the .cpp file (it's in C:/Program Files/Common Files/lodepng/lodepng/lodepng.cpp). But how do I tell it that?
Currently the fix I'm using is to simply drag and drop loadpng.cpp into my Source Files of the project, but this isn't a very nice solution.
Any ideas?
You have to add your .cpp files to (compile with) your project.
Right click the project in the solution explorer, then select Add -> existing item and select your .cpp files. Note the folder the files live must be inlcuded to your diretories
VC++ would only look files for you when encountering directives like:
#include "lodepng.h"
Though possible it is not a common practice to include a cpp file, in fact you could include text file for example to include very large data file etc.
Best practice is to add cpp file into your project, don't put any cpp file in a header folder and don't include them unless there are no any alternatives.
I am having a problem of getting compile errors (red underlines) like:
Error: cannot open source file "stdafx.h"
Here an edited screenshot of the environment:
On the LEFT is my Visual Studio Solution Directory list with the "Show All Files" off.
I am working on a school project, and each Folder are the source files of different parts of the project with different people who are in-charge of them.
For example, Student A and B are incharge of AST and PARSER folders (we will call them sub-projects).
We have an API for each sub-project so other sub-projects know what to call.
At the TOP-CENTER, we have my Source File for a class QueryProcessor. (just the first few lines)
Below it, is the Output for the Build Success.
The red lines are all over all the classes, mainly cause the #include "stdafx.h" cannot be opened by the environment.
On the RIGHT, that is the stdafx.h where we include all the different sub-projects so we save the trouble of each project having a different stdafx.h
However, I am able to build the project. I am pretty sure I am doing this directory/linking wrongly.
This should work
Right click on the solution file
Click Open in Windows Explorer
Find file stdfx.h in explorer and copy the path of the folder
In visual studio solution explorer, Right click on the project file
Click properties-> C/C++ -> General
In the Additional Include Directories paste the path
Combining folders and virtual folders in VC is from my point of view messy because the virtual folders indicate that all files are in one directory and the folders created on the harddrive obviously indicate that all files are in different directories. You can combine it if you know what's going on but in your case I would not recommend it.
I assume you missunderstand the purpose of stdafx.h The purpose of this header file is NOT to put all header filles into it and then just include it to all other files. Here is a SO question about this Purpose of stdafx.h
After cleaning up your stdafx.h file include as many header files into your .cpp files and only put these includes in your header files if they are required in the header file
Turn on show all files, now you will work with actual folders and you can be sure that if you adress a folder like "PKB" that this folder really exists since you can see it in the left solution explorer.
If you use using namespace std; for example make sure you also include the required header files. You might think "hey I already included e.g. iostream in another header file which I now include in this header file so I don't need it" That will really destroy you when you work with bigger projects.
Oh and regarding the stdafx.h include problem as soon as you switch to show all files I assume you will realise that stdafx is in a different file than the file where you use the include. Maybe something like #include "..\stdafx.h" is required (depending on your structure).
I think it's obivious but if you include a header file the include is allway relative to the file which is including the other header file.
stdafx.h is commonly used for creating a precompiled-header, which essentially is a compile-time optimisation such that the compiler will not continually compile these headers for every compilation unit.
If any of these headers changes, you will need to do a full system rebuild.
In reality it is preferable only to use it to include standard headers plus third-party headers (like boost libraries and similar) that you are not ever going to change.
You may decide that some of your own libraries are "set in stone" and can also be included.
Every project, i.e. every part of the project that is built into a separate unit (DLL or .exe) should have its own precompiled header and its own version of stdafx.h
Projects should only ever include their own .stdafx and not those of other projects, therefore this header file can also be used to define your dllexport macro.
When arranging your project headers you should be aware of:
1. Which headers are included externally
2. Which headers are only included internally, and are not even included indirectly externally.
The latter sort should include your stdafx.h file and should ideally not be in the same directory as those headers included from outside your project.
I have a.cpp and a.h files in separate from the main project directory. I include a.h header file into main project using absolute path. Hot to tell c++ where it must look for a.cpp file?
The best way is to just add the cpp file to the project.
If it's outside the project or excluded from the build, you could include it in a another source file (#include "othercpp.cpp") and specify its path in the additional include directories under project settings.
But the correct approach would be to add it to the project. It doesn't have to be in the same place as other cpp files for this.
If your .cpp is in the project, it will find it. If it is not, you might work around that with the include directories, but thats just bad practice.
Visual studio normally compile all the cpp files included in the project,
so you don't need to 'find' it actually. Just drag it into current project.
Add the a.h to your projects default header file location. Do the same for your a.cpp. Add both the files to your project. You can now successfully build.
When I say add them to the default location, I mean the actual physical location that your main.cpp for the project is located as well as the header files for your project is located. If you put them anywhere else you will need to "Add additional include" directory paths for your header file.
In my place we have a big C++ code base and I think there's a problem how header files are used.
There're many Visual Studio project, but the problem is in concept and is not related to VS. Each project is a module, performing particular functionality. Each project/module is compiled to library or binary. Each project has a directory containing all source files - *.cpp and *.h. Some header files are API of the module (I mean the to the subset of header files declaring API of the created library), some are internal to it.
Now to the problem - when module A needs to work with module B, than A adds B's source directory to include search path. Therefore all B's module internal headers are seen by A at compilation time.
As a side effect, developer is not forced to concentrate what is the exact API of each module, which I consider a bad habit anyway.
I consider an options how it should be on the first place. I thought about creating in
each project a dedicated directory containing interface header files only. A client module wishing to use the module is permitted to include the interface directory only.
Is this approach ok? How the problem is solved in your place?
UPD On my previous place, the development was done on Linux with g++/gmake and we indeed used to install API header files to a common directory is some of answers propose. Now we have Windows (Visual Studio)/Linux (g++) project using cmake to generate project files. How I force the prebuild install of API header files in Visual Studio?
Thanks
Dmitry
It sounds like your on the right track. Many third party libraries do this same sort of thing. For example:
3rdParty/myLib/src/ -contains the headers and source files needed to compile the library
3rdParty/myLib/include/myLib/ - contains the headers needed for external applications to include
Some people/projects just put the headers to be included by external apps in /3rdParty/myLib/include, but adding the additional myLib directory can help to avoid name collisions.
Assuming your using the structure: 3rdParty/myLib/include/myLib/
In Makefile of external app:
---------------
INCLUDE =-I$(3RD_PARTY_PATH)/myLib/include
INCLUDE+=-I$(3RD_PARTY_PATH)/myLib2/include
...
...
In Source/Headers of the external app
#include "myLib/base.h"
#include "myLib/object.h"
#include "myLib2/base.h"
Wouldn't it be more intuitive to put the interface headers in the root of the project, and make a subfolder (call it 'internal' or 'helper' or something like that) for the non-API headers?
Where I work we have a delivery folder structure created at build time. Header files that define libraries are copied out to a include folder. We use custom build scripts that let the developer denote which header files should be exported.
Our build is then rooted at a substed drive this allows us to use absolute paths for include directories.
We also have a network based reference build that allows us to use a mapped drive for include and lib references.
UPDATE: Our reference build is a network share on our build server. We use a reference build script that sets up the build environment and maps(using net use) the named share on the build server(i.e. \BLD_SRV\REFERENCE_BUILD_SHARE). Then during a weekly build(or manually) we set the share(using net share) to point to the new build.
Our projects then a list of absolute paths for include and lib references.
For example:
subst'ed local build drive j:\
mapped drive to reference build: p:\
path to headers: root:\build\headers
path to libs: root:\build\release\lib
include path in project settings j:\build\headers; p:\build\headers
lib path in project settings j:\build\release\lib;p:\build\release\lib
This will take you local changes first, then if you have not made any local changes(or at least you haven't built them) it will use the headers and libs from you last build on the build server.
I've seen problems like this addressed by having a set of headers in module B that get copied over to the release directory along with the lib as part of the build process. Module A then only sees those headers and never has access to the internals of B. Usually I've only seen this in a large project that was released publicly.
For internal projects it just doesn't happen. What usually happens is that when they are small it doesn't matter. And when they grow up it's so messy to separate it out no one wants to do it.
Typically I just see an include directory that all the interface headers get piled into. It certainly makes it easy to include headers. People still have to think about which modules they're taking dependencies on when they specify the modules for the linker.
That said, I kinda like your approach better. You could even avoid adding these directories to the include path, so that people can tell what modules a source file depends on just by the relative paths in the #includes at the top.
Depending on how your project is laid out, this can be problematic when including them from headers, though, since the relative path to a header is from the .cpp file, not from the .h file, so the .h file doesn't necessarily know where its .cpp files are.
If your projects have a flat hierarchy, however, this will work. Say you have
base\foo\foo.cpp
base\bar\bar.cpp
base\baz\baz.cpp
base\baz\inc\baz.h
Now any header file can include
#include "..\baz\inc\baz.h
and it will work since all the cpp files are one level deeper than base.
In a group I had been working, everything public was kept in a module-specific folder, while private stuff (private header, cpp file etc.) were kept in an _imp folder within this:
base\foo\foo.h
base\foo\_imp\foo_private.h
base\foo\_imp\foo.cpp
This way you could just grab around within your projects folder structure and get the header you want. You could grep for #include directives containing _imp and have a good look at them. You could also grab the whole folder, copy it somewhere, and delete all _imp sub folders, knowing you'd have everything ready to release an API.
Within projects headers where usually included as
#include "foo/foo.h"
However, if the project had to use some API, then API headers would be copied/installed by the API's build wherever they were supposed to go on that platform by the build system and then be installed as system headers:
#include <foo/foo.h>