I don’t know about you, but I usually have a fever and complete prostration in my thoughts when I need to write something from scratch. In my head various abstract models are already flying, from what and where. But you can’t grasp for any of them, because you’ve got a clean sheet and pulled one thought out of my head, there’s nothing to apply it to, and you’re not able to pull out the whole skeleton because you are already thinking about solving the problem, but you still need write the backbone of the application.

Below is the “NULL project”, the very backbone with which everything usually begins. I have.

This post most likely will not be of interest to those who are already experienced and those who are not directly involved in C ++ development, since The material presented below carries one single goal - to give a ready-made foundation to begin with.

Requirements

I will try to highlight for the beginning a number of requirements that it would be nice to implement in this core

1. Project folder
2. CMake build scripts and scripts for generating solyushinov
3. start and stop scripts
4. the application should start, work and exit correctly, the whole process should be logged
5. you can log in to the console, anyway, each project has its own logger, the main thing is that it would be easy to replace.
6. the application should parse the command line
7. the application should be able to parse the configuration file of the form key = value
8. project without boost? no, have not heard. So immediately integrate boost
9. error processing. Since this is only the backbone and here, in fact, there is no performance, then we do on exceptions.
10. do the world capture function

Project folder

. ├── CMakeLists.txt ├── gen_eclipse.sh ├── include │  ├── logger.h │  ├── mediator.h │  ├── pid.h │  ├── program_options.h │  ├── thread.h │  └── version.h ├── package.sh ├── src │  ├── logger.cpp │  ├── main.cpp │  ├── mediator.cpp │  ├── pid.cpp │  ├── program_options.cpp │  └── version.cpp ├── start.sh ├── stop.sh └── version.sh 

Solyushinov generator

The goal of the gen_eclipse.sh script is to prepare a folder structure and call cmake to generate debug and release solos. And also set the current version of the project. It so happened that I usually develop on Linux systems in the Eclipse environment, hence the name gen_eclipse. But I did not succeed in fully fostering Cmake and Eclipse. In order to open a generated project in Eclipse, you need to import an existing MAKE project, with either release or debug, and add links to the include and src directories via the context menu.

Version

The first thing to note is that I use Subversion and rely on revision numbers as versions. I usually stick to the following version format: MAJOR.MINOR.REVISION. The first two values ​​are given by pens, the third is the svn revision. As far as I know, the subversion client cannot return just the revision number, so I use the following mechanism

 REVISION=`LANG=C svn info | grep "Last Changed Rev:" | sed s/"Last Changed Rev":\ //` if [[ "$REVISION" == "" ]]; then echo "Cannot recognize number of revision" exit 1 fi ... VER_CPP=src/version.cpp echo "#include \"version.h\"" > $VER_CPP echo "const char* VERSION = \"$VERSION\";" >> $VER_CPP 

Startup, Stop Scripts

As a rule, all the software that had to be written under Linux was servers, large and small. Their peculiarity is that they work in the background, these are services. I know that for such things it is customary to have start and stop scripts in the init.d directory. But! I have not had a single case where only one version of the service would be started on one server. Therefore, I adhere to the practice of start stop scripts with control on the PID file.

The shutdown script has a much more sophisticated logic, for slow shutdown of the server.

Ps. Thanks to my colleague Andrew for offering a more usable version of the stop.sh script

Package.sh

In each of the projects I have a script package.sh whose goal is to create an adequate installation package. As a rule, this is an archived application folder with a set of files sufficient for the application to work. The minimum set is the stop start scripts, the configuration file, the application itself, and the folder for logs.

Functional

And so, what I usually need in order to proceed directly to programming:

1. Command Line Parameters
2. configuration file
3. A simple way to interact with the logger
4. The ability to stop the application correctly

Let's start in order:

Command Line Parameters

I selected for myself three such parameters. Now I will try to explain why they are.
Directory for logging. The reason why I do not store this parameter in the configuration file is that during the parsing of the configuration file errors that I want to log can happen. Why a directory? I'm used to the fact that each launch is a separate log file, thus, it is easier to delete old logs.
Configuration file If not through the command line, how? Especially if you have several configurations that you want to quickly switch.
PID file. The only reason why I do not store it in the configuration file is that this parameter is used in 2 places at once. In start and stop scripts. And it is much easier to put it into a separate init file, which is connected to start stop scripts, and edit it once, rather than two (I’m talking about the conf file).
')
Analysis of the command line and the configuration file is done by means of boost :: program_options

Each parameter has default values.

./projectnull -h
Allowed options:
-h [--help] produce help message
-c [--config] arg (= project.conf) set configuration file
-l [--logdir] arg (= logs) set log directory
-p [--pidfile] arg (= project.pid) set pid file

Logging

I did not begin to invent the logger, as a rule, in each firm it the. In this project, I limited myself to outputting to the console, in the Note and Error modes. The only requirement I place on the logger is that it must support an interface like printf. Agree with me because printf is wonderful. I just added macros for a convenient logging process.

Stop

In my opinion, the correct stop is one of the most important functions of the software which is often forgotten. As a rule, to make a correct stop in an already developed software is an impossible task. Another thing, if you stick to a certain strategy from the very beginning, then it becomes a trifle. I do not consider all sorts of sophisticated ways to get a shutdown command over the network, via SMS or via satellite. I just catch some signals, then initiate the procedure for a correct stop.

 void Mediator::wait_exit() { LOG("Set up waiting exit"); sigset_t set; int sig; sigemptyset(&set); sigaddset(&set, SIGINT); sigaddset(&set, SIGQUIT); sigaddset(&set, SIGTERM); sigaddset(&set, SIGTSTP); sigprocmask(SIG_BLOCK, &set, NULL); sigwait(&set, &sig); switch (sig) { case SIGINT: case SIGQUIT: case SIGTERM: case SIGTSTP: LOG("Catched signal to stopping application"); stop(); break; } } 

The only thing that is required is to call the wait_exit () function in the main thread, after performing all the active actions.

  LOG("Appication started, version: %s (%s)", VERSION, BUILD_TYPE); { Mediator mediator; mediator.start(); mediator.wait_exit(); } LOG("Applicatiom stopped"); 

Thanks to mejedi for pointing out the incorrect use of a signal handler for these needs. I hope I correctly interpreted (implemented) your proposal.

Application structure

So we got to the final part. As it has already become clear to many, I use the “Mediator” pattern. Of course, not in all its glory, because no business has logic yet.

 class Mediator: public Thread { public: Mediator(); virtual ~Mediator(); void wait_exit(); private: virtual void run(); void load_app_configuration(); void create_pid(); private: Pid pid_; }; 

If some work is supposed to be performed in a separate thread, then for such a task there should be a separate class inherited from the special class Thread.

 class Thread { public: void start() {th_ = boost::thread(boost::bind(&Thread::run, this));} void stop() {th_.interrupt(); th_.join();} virtual ~Thread(){} private: virtual void run() = 0; private: boost::thread th_; }; 

The purpose of which is to support the start and stop process in a single format.

Repository

The project is available in Google Code, but only for read-only. It's not because I'm greedy, I just don't know how to open access for everyone. If you wish to make changes, write your g-email, add you to the project.

 svn checkout http://project-null.googlecode.com/svn/trunk/ project-null-read-only 

A couple of words...

The idea to arrange this development in a tangible pattern came to me about two months ago, in the process of the next project that needed to be installed quickly and from scratch. During the writing of the project, I came to the conclusion that this is not the first time that I have a similar architecture, and that it makes no sense to remember all the pitfalls each time and come to the same solution that I used before, you need to arrange it as a template. I suffered for a long time at the expense of writing this article, but remembering the parable about the teacher and a glass of water, I decided that they would better tell me that the article was not worth a penny than I would continue to think about its expediency.

Thanks for attention.

Ps. Added various PID file checks at startup. Cases are processed with a PID file - there is no process, the PID file is empty.