Source file organisation - c++

I am having a bit of trouble organising my source files.
I have my own small, but growing collection of code that I would like to use in various projects. The file and folder layout is something like this:
library\sub1\source.h
library\sub1\source.cpp
library\sub2\source.h
library\sub2\source.cpp
One of my problems is that I want to include this code, as needed, in my other projects. To date I have used absolute paths to point to the libary code, but there must be a better way.
Futhermore, I need to add every library file I use to a project's files Visual Studio in order for it to compile correctly.
So my question in short is how do I fix this? What is the proper/best way to handle the above situation.

You shouldn't, in general, add source files from libraries directly to other projects. Compile them separatly as a library and use those.
For organising the library's directory structure itself, right now I settled on something like the following structure
library1/widget.h
library1/private/onlyinlib.h
library1/private/widget.cpp
(and if applicable)
library1/private/resources/widget.jpg
library1/private/project/widget.xcode
I put all headers directly in the library path, and have a subfolder private which will contain everything that's only used by the library, but should never be shared / exposed.
The greatest advantage is that every project I start only needs a include path pointing at the directory containing my libraries, then every (public) include is done like
#include "library1/widget.h"
private includes are simply
#include "onlyinlib.h"
This has a number of advantages:
If new libraries are introduced, there's no messing with project /compiler settings to get the headers 'visible'.
Moving to other compilers / platforms is also very little hassle.
The headers are automatically 'namespaced', i.e. by including part of the path too, it's next to impossible to get a nameclash with the includes
It's immediatly obvious where a header comes from, and if a header is part of the public interface or not

I don't think that there's a proper way to do this - it's going to depend on exactly what you are trying to achieve.
Here's some things you might not be aware of:
You can use relative paths in your projects.
You can use environment variables in paths.
You can add directories to Visual Studio's search rules.
This gives you a little more control over where you put the include files and if you add your folders to Visual Studio's search rules you don't have to include any paths at all.

If you must include third-party code instead of just linking with a pre-compiled version (e.g., perhaps you need to make modifications or tweaks to it), consider branching it in whatever you use for source-control:
/trunk/... --- your code goes here
/thirdparty --- pristine copies of third-party libraries go here
/thirdparty/lib1
/thirdparty/lib2
etc.
/trunk/lib1 --- branched from: /thirdparty/lib1, perhaps with local changes
this is the version that you build/link with.
Assuming you use a decent source-control system, this scheme will allow you to easily upgrade to newer versions of third-party libraries and then merge those changes with the changes you've made locally.
For example, suppose "lib1" releases a new version:
Commit the change to /thirdparty/lib1.
Merge from /thirdparty/lib1 to /trunk/lib1
Fix any merge conflicts.
This is, IMO, the only sane way to handle upgrading third-party libraries to which you've made local modifications.

First: Add all used directorys to your project include paths. Add them as relative paths if possible.
Second: You must add all used librarys/source files to your project. This can be either done in the project explorer, or in the Project->Linker tab. In the latter case, you'll have to add the used directories to the projects library paths as well.
Usually its not a good idea to use paths in #include directives.

Related

Change include paths

I have a C++ solution that uses several external libraries. For that to work, the compiler needs to be able to find all the header files. Currently this works by hard-coding the header locations into the various project files. But since the headers are installed in a different location on each computer, that means the project will only build on one machine.
What is the "correct" way to deal with this problem?
I feel like there should be a way to define which libraries each project needs, and then a separate file somewhere that says where those libraries are on this particular machine. But I don't know if MSBuild has anything remotely like that.
(Obviously, as well as the header files, we have exactly the same problem with the linker needing to find the object code to link in.)
It seems you can in fact fix this using environment variables. Either through the Visual Studio user interface itself, or just by editing the *.vcxproj file in a text editor, edit the include path from
D:\Libraries\Boost\32bit\include;D:\Libraries\GTest\32bit\include
to instead be something like
$(BOOST_ROOT)\include;$(GTEST_ROOT)\include
Now the project builds on any machine where the environment variable %BOOST_ROOT% is set to the right folder path. (And likewise for %GTEST_ROOT%.)

c/c++ relative include paths vs Makefile include flags

In a large project that has files structured in a directory tree structure, is it better to include relative path in source file, or just include header file and instruct compiler via Makefile where to find it?
Is there a preferred way?
Example:
#include "../path/to/file.h"
vs.
#include "file.h"
gcc -I../path/to
I believe that first case may be more readable while second approach would give ability to seamlessly move files...
It depends. For include files inside your project, giving the relative path can be useful, as the sub-directory is another structure-element and you do not have to care about equal file-names (mostly for C++, as C does not support custom-namespaces).
For external paths (e.g. other projects), you should definitively use the second method. Possibly just to the root of that structure. Similar to asm/byteorder.h.
In any way, if using explicit paths (in the source files), you should make sure they are well-documented and any change is tracked to the source files. (There are often common sub-directories, like config, etc. which will not change).
One strong recommendation: always use the project root as working directory. All explicit relative paths are from this root. That way you can avoid the problemativ parent (..) path.
Ultimative rule is not to use explicit paths which cross the project-root.
However, there is no other general rule. The actual layout is often subject to personal preferences. If the directory structure is well-thought, I'd prefer explicit paths.
The second method is more efficient since you don't have to rewrite the path every single time you want to use this file.
Let's take an example.
You want to build a library containing some useful functions.
Then you work on a project on which you need some of the library's functions, not all of them.
So you choose to mv some on those files into your project folder.
This way, the path might not be the same, and you won't have to rewrite everything if you choose to include the path in the Makefile.
Coding your Makefile properly, let you have several $(PATH), which is very useful when working on big projects requiring multiple binaries for example.
I'm trying to be as clear as possible, but I really think, in my opinion, that the Makefile is a very powerful tool which can be used to his best to make the project development easier.

visual c++ include folders, libraries, etc

I'm an engineer, not a strong programmer. I'm writing some simulations using openGL and freeglut. I develop on my computer at home or at school or work so I need to keep everything contained. Typically I've gotten things to work by placing needed libraries in my solution folder and linking to them in the project properties. Any header files I've also put in the solution folder (or subfolder if already defined e.g. GL/freeglut.h). Then in my source files I use a command like #include "GL/freeglut.h" with quotes. In my most recent project I'm having problems with another set of headers that deal with hardware that have classes with the same name. It is my understanding that if you keep your headers in separate folders and be careful with namespaces there shouldn't be a problem. I can also configure additional include folders for the project then I use a command like #include <GL/freeglut.h>. What is the best way to set all of this up?

Separate "include" and "src" folders for application-level code? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
This questions concerns mostly Unix/Linux style C++ development. I see that many C++ libraries store their header files in a "include" folder and source files in an "src" folder. For the sake of conformance I adopted this in my own code. But it is not clear to me whether this should be done for application code as well. I've seen a few cases where a flat directory structure is used for that. What would be the recommended approach?
I also separate them, but not strictly on the extension, but on the access of the file.
Suppose you have a module that manages customer information and uses 2 classes to do this: Customer, CustomerValidityChecker.
Also suppose that other parts in your application only need to know about the Customer class, and that the CustomerValidityChecker is only used by the Customer class to perform some checking.
Based on these assumptions I store the files like this:
Public folder (or include folder):
customer.h
Private folder (or source folder):
customer.cpp
customervaliditychecker.h
customervaliditychecker.cpp
That way, it becomes immediately clear for callers of your module which parts are accessible (public) and which parts aren't.
We have a build system that auto-generates our makefiles. One thing it does is recursively descend any subdirectories and build them as libraries, linking them together with the main directory's objects to make the application. (In practice, these "subdirectories" are usually symbolic links.) Libraries are static unless the directory name ends in ".so". One thing that's nice about this is that a full build of our system, which has many executables, doesn't have to repeatedly compile the common libraries.
However, as a result of this, there's no separation of headers and sources. And it has never been a problem. Honestly, I think it's better this way because headers and source files have commonality of location, and you can grab a directory and know you got everything you need to use it. It also works great with Subversion's "externals" feature, and similar features in other VCSs.
One last place where an include/src separation fails is if you use any code generators, such as flex, bison, or gengetopts. Figuring out where these tools should put their outputs so they get built is tricky if you've spread things out.
It makes sense to separate them for shared libraries because they may be distributed in a compiled form without the source. I've seen projects that separate out "public" headers (headers that may be accessed from code outside your project or library) while leaving "private" headers and source files in the same directory. I think it's good to use a consistent approach whether you're writing shared library or application level code because you never know when you may want to turn something that you've written at the application level into a lower level library that is shared by multiple projects.
A lot depends on the size of project involved. Up to a few dozen files or so, keeping them in one directory tends to be more convenient. For a bigger application that includes hundreds or thousands of files, you start to look for ways to separate them (though in the projects I've worked on, it was done more on functional lines than src/include). In between those, it's probably open to question.
I don't do this; there seems little advantage in it. Since headers tend to have a different extension from source files, you can have your editor show them separately if you really feel the need -- Visual Studio does this by default, but I disable it since I prefer seeing them together
Bottom Line: sources and headers that are still changing go in /src. Code that has crystallised should go in /lib & /include (actually you could keep all .libs and their .hs in /lib).
Keep own sources and headers together, provided they are (a) specific to this project or (b) have not yet been factored out as a shared library.
Once certain sources in the main project have been factored out as a (relatively stable) library, place the .a or .lib into /lib, and its public interface header into /include.
All third party libraries and their public interface headers also go into /lib & /include.
As others note, it is often more compatible for tools / IDEs to access .h/.c from one folder. But from an organisational view it can be useful to separate changing local code from stable lib code.
There is no clear advantage to either in my view. I finally decided to keep program and header files together because my editor (Visual SlickEdit) happens to provide additional referential features when they are not separated.
I almost always create include and src folders to split up my source code. I think it makes the folder less cluttered and files are easier to find in my IDE. But I think this is just a matter of taste.
Either method is valid. It depends on the coding style you want to follow how you do this.
I place include (header) and source files in the same directory (folder). I create different folders for different themes. I get frustrated when trying to find header files (while debugging and also for researching). In some shops, there are only two folders: source and includes. These directories tend to grow exponentially. Reusing code becomes a nightmare at best.
IMHO, I believe organizing by theme is better. Each theme folder should build into at least one library. Different projects can easily include the themes by searching or including the folders. The projects only need to include the libraries. Smart build engines can list the theme folders as dependencies. This speeds up the build process.
The theme organization also adds a bit of safety to the project. Accidental damage to files (such as removing the wrong ones or replacing with different versions) is reduced since files are located in different directories. Deletion of files in the "Person" folder will not affect files in the "Shape" folder.
This is just my opinion, Your Mileage May Vary.
We have a build system which use this rule. This build system is sconspiracy a set of scripts to configure SCons and dedicated to the C++ world. You can see an example which use this tools : fw4spl

Organising .libs in a codebase of several C++ projects

Let's say you have several bespoke C++ projects in separate repositories or top-level directories in the same repository. Maybe 10 are library projects for stuff like graphics, database, maths, etc and 2 are actual applications using those libraries.
What's the best way to organise those 2 application projects to have the .libs they need?
Each lib project builds the .lib in its own directory, developers have to copy these across to the application area manually and make sure to get the right version
Application projects expect lib projects to be in particular paths and look for .libs inside those locations
A common /libs directory is used by all projects
Something else
This is focused on C++, but I think it's pretty similar with other languages, for instance organising JARs in a Java project.
I'd suggest this approach:
Organise your code in a root folder. Let's call it code.
Now put your projects and libraries as subfolders (e.g. Projects and Libraries).
Build your libraries as normal and add a post-build step that copies the resulting headers and .lib files into a set of shared folders. For example, Libraries\include and Libraries\lib. It's a good idea to use subfolders or a naming convention (myLib.lib, myLib_d.lib) to differentiate different builds (e.g. debug and release) so that any lib reference explicitly targets a single file that can never be mixed up. It sucks when you accidentally link against the wrong variant of a lib!
You can also copy third-party libraries that you use into these folders as well.
Note: To keep them organised, include your files with #include "Math\Utils.h" rather than just "Utils.h". And put the headers for the whole Math library into include\Math, rather than dropping them all in the root of the include folder. This way you can have many libraries without name clashes. It also lets you have different versions of libraries (e.g. Photoshop 7, Photoshop 8) which allows you to multi-target your code at different runtime environments.
Then set up your projects to reference the libraries in one of two ways:
1) Tell your IDE/compiler where the libs are using its global lib/include paths. This means you set up the IDE once on each PC and never have to specify where the libs are for any projects.
2) Or, set each project to reference the libs with its own lib/include paths. This gives you more flexibility and avoids the need to set up every PC, but means you have to set the same paths in every new project.
(Which is best depends on the number of projects versus the number of developer PCs)
And the most important part: When you reference the includes/libs, use relative paths. e.g. from Projects\WebApp\WebApp.proj, use "..\..\Libraries\include" rather than "C:\Code\Libraries\Include". This will allow other developers and your buildserver to have the source code elsewhere (D:\MyWork instead of C:\Code) for convenience. If you don't do this, it'll bite you one day when you find a developer without enough disk space on C:\ or if you want to branch your source control.