KISSCPP
a C++ library for rapid application development
|
All but the most trivial of applications, require logging at some level. KISSCPP has been designed with logging in mind, and presents the developer with a mechanism that closely emulates C++ streams, through the use of the LogStream class.
Each KISSCPP application is restricted to having one log file, but you can log to that file, from anywhere in the application.
There are nine log levels, divided into three log types and each log type has three severity levels.
The three types of logs are error, info and debug. Refer to the table below for more detail on each.
Log Type | Purpose |
---|---|
error | Used to log actual processing errors, logs of this type are always at a higher log level than other log types. |
info | For logging things that are valuable information on a live system. Typically things like business logic events. |
debug | For use during development and stabilization of your applications. You should not be using this log type on a production system. |
Each of the above log types have three levels of severity associated with them. Those severities are low, normal and high.
The combination of a log type and severity, gives you a logging level. The table bellow shows the various log levels associated with a type and severity combination.
Log Level | Type | Severity |
---|---|---|
9 | error | high |
8 | error | normal |
7 | error | low |
6 | info | high |
5 | info | normal |
4 | info | low |
3 | debug | high |
2 | debug | normal |
1 | debug | low |
KISSCPP defaults to a logging level of 5.
i.e. logs of type info with severity normal, or combinations that result in a higher log level, will be written.
Yes, that is honestly how simple it is. KISSCPP will not support the ridiculous number of logging levels supplied by other libraries. If a developer can not work with only 9 log levels, 15 levels won't be enough either. There will be no support for so called "log filtering" either. Filtering huge amounts of text is well covered by tools like grep, sed and awk. Even the most stringent logging practices, are easily managed with those tools.
The header file you'll be needing is:
And here is an example of some code:
Where:
e.g.
KISSCPP applications will have log files named as follows:
i.e. An application with the id foo, being executed with an instance identifier of bar will write to a log file named:
As with configuration files KISSCPP has to consider more than just the developer. So here again, we have to enforce some standards. You will therefore only have control over the root directory where log files reside.
The default directory for logging, regardless of operating system, is **/tmp**. This can be over ridden through the use of the KCPP_LOG_ROOT and KCPP_EXEC_ENV environment variables.
The log file path, is constructed thus:
That means, when you have a KISSCPP application with the name foo and you start instance bar of it, while having KCPP_LOG_ROOT set to /put/logfiles/here
Your application will place log files in:
Meaning that the full path to the log file will be:
If you take the extra measure of using KCPP_EXEC_ENV and set it to a value live, your application will write that same log file to: