C++ application development ( Part 1 — Project structure )
If you come from a web development background, and ended up learning C++ for some fortunate reason you must have ended up at this point at some point of time. Now if you are like most authentic coders, you must have started digging to see what experienced coders do to structure their code. Ironically even though C++ is really old and mature, the docs that are available out there are not very appealing to the current generation of coders who have been reading web framework docs which are easy to understand and follow. I don’t know why people have not taken such an initiative for C++. But truth be told, it is not an easy language to learn.
In the web, these kind of tasks are usually automated. Third party libraries are also managed and added/removed by package managers ( Something that the C++ ecosystem lacks ). This gives you an opportunity to take full control of your project, and best of all, learn how things work under the hood. I will try to keep things as detailed as possible. There are two things C++ coders are concerned with while working on a massive project —
- Maintaining a project structure
- Dealing with third party libraries
In this article we will be concerned with the former. We will also talk about CMake, a tool that will be used to bind the project together.
So let us now get to the meat of this article — The project structure. After reading a few docs and consulting a few good coders, I have come to an sturdy project structure that shall avoid confusion and should keep your code clean and clutter free. Here is the layout, let us break it down one by one.
Note: Basically what we are making is a library which you might use directly or might be used as a third party library by some one else. The key idea is to separate the public header files from the private ones, ie. you need to have some kind of control over which functions people using your library can invoke and which ones are strictly from internal use.
1. include/
By convention, include directory is for header files, but modern practice suggests that include directory must strictly contain headers that need to be exposed publicly. A thing to note here is the use of another directory inside the include directory. What is even more interesting is that it has a name same as that of your project. The reason to do this is to give a sense of specification when someone tries to use your library. Thus to use your library, one has to use the code
#include <Project_Name/public_header.h>instead of
#include <public_header.h>which basically makes it look kind of generalized.
Obviously the head file in this directory will be exposing those functions and classed that can be publicly called and used by someone using your library.
2. src/
This directory basically contains all the source code and the header files that are for internal use only. All the code that you library/project consists of must go in here.
3. libs/
This directory consists all the third party libraries that are need by your project. Usually if you look into any of the third party libraries present here, they would be following a similar structure that you are using for your project.
A point to note is there are two ways of using third party libraries in C++ — static and dynamic. This lib directory is only for static ones. We will discuss more on this later in a separate article ( Part 4 of this series).
4. test/
As the name suggests, code for unit testing is kept in this directory.
5. CMakeList.txt
This file is basically a configuration file that tells CMake what to do. We will talk in detail on CMakeList.txt in Part 2 of this series. Keep in mind that CMake is not a build system, but a build system generator. To understand this statement, you must know the difference between Make and CMake. We will get to this when we talk about CMake in the next article.
Once you understand what CMake does and how all this comes together to generate your final binary, every thing will be crystal clear and you shall have no problem building a new project from scratch.
“You can’t trust code that you did not totally create yourself” — Ken Thompson
