
Introducing Pantheios Logging Library
One way or another, everyone had to embed a logging system in their program. Many write their own, because consider that it is smarter than others its most optimal. Others use ready-made libraries that can greatly simplify life.
Today I would like to talk about the Pantheios logging library, which, according to the creators, has great speed , multi-threading, unicode support and simultaneous output to different log recipients.
I will consider the logger with t.z. use on Windows, with the compiler that comes with Visual Studio 2010 SP1, given that I would like to have the logs in UTF-16LE (in the file) and at the same time output them to the console in paints. It is also important for me to be able to output logs to skiers in Unicode mode in order to support output in national alphabets.
The article is written for beginners and for quick familiarization with the library.
So, for the assembly we need the actual source files pantheios and stlsoft.
The first can be downloaded from here , and STLSoft STL from here .
For definiteness, I took the latest available stable source versions of pantheios-1.0.1-beta211 and stlsoft-1.9.108.
Unpack the resulting sources in C: \ temp and proceed with the assembly.
Launch the VS2010 console, where we specify the STLSOFT environment variable and run the build: and have a smoke while everything is assembled. The result will be in. If you look briefly at lib, you can see a large number of libraries compiled in different build modes.
But there are kind people who wrote a utility for choosing the operating modes of the logger, which gives a good clue how to turn this soup set of libraries and headers into a working logger.
The library is actually divided into cheters of the layer:
The core is the connecting part of all other parts of the library.
The API for applications is just that set of functions that we can use directly to output to the log in our application.
Front-end - a subsystem responsible for filtering attempts to display messages by logging level.
Back-end is a subsystem that is responsible for outputting messages to a specific recipient (file, console, syslog, etc.), as well as for configuring this recipient (output format for example).
You can read more about architecture on the page: the project itself .
We will define the environment variables as follows and run VS2010: Create a standard C ++ Console Project and configure the project so that it can see our library through the environment variables: It's time to start writing the test itself. As we recall, the task was set earlier: output to the log and to the colorful console in UTF-16 simultaneously. For these purposes, you and I must use two Back-Ends: a cosnol and a file. Both the back and front end can be connected to the program using pre-prepared include files. This greatly simplifies the configuration of logging. To further simplify the configuration, a utility was written where you can choose the combination of the necessary headers. You can take it here . Its external interface is quite simple:



Actually, the screenshot shows just the options we need.
Briefly explain:
The rest, I think, is intuitive.
Ok, now we can copy and fix what the utility generated for us (yes, she made a mistake in choosing be.ltsplit, it’s probably the file where it was renamed that was not taken into account in the utility). We must also supplement the include directly with nuclear.
As a result, we get the following files:
Now we must take into account that fe.simple requires the application name to be additionally defined (for indication in the log file).
To do this, declare a variable:
Well, actually now we implement our test:
and get the result:

and similar (but without color) in the local.log file .
We examined the very basic part of the pantheios logger, but it still has a lot of interesting things.
The advantages include speed, unicode support out of the box, cross-platform, type-safe-ing.
Of the minuses, I would single out a rather confusing use procedure and unsupported configuration from a file. However, often, these minuses can be ignored.
Overboard there is a comparison with other loggers, advanced configuration (output format), maybe this will appear in another note.
Thanks to those who read to the end and have a good weekend!
Today I would like to talk about the Pantheios logging library, which, according to the creators, has great speed , multi-threading, unicode support and simultaneous output to different log recipients.
General remarks
I will consider the logger with t.z. use on Windows, with the compiler that comes with Visual Studio 2010 SP1, given that I would like to have the logs in UTF-16LE (in the file) and at the same time output them to the console in paints. It is also important for me to be able to output logs to skiers in Unicode mode in order to support output in national alphabets.
The article is written for beginners and for quick familiarization with the library.
Library
- Main library site: http://www.pantheios.org/
- License: BSD-style license
- Depends on: STLSoft STL ( http://www.stlsoft.org/ )
Library assembly
So, for the assembly we need the actual source files pantheios and stlsoft.
The first can be downloaded from here , and STLSoft STL from here .
For definiteness, I took the latest available stable source versions of pantheios-1.0.1-beta211 and stlsoft-1.9.108.
Unpack the resulting sources in C: \ temp and proceed with the assembly.
Launch the VS2010 console, where we specify the STLSOFT environment variable and run the build: and have a smoke while everything is assembled. The result will be in. If you look briefly at lib, you can see a large number of libraries compiled in different build modes.
>SET STLSOFT=c:\temp\stlsoft-1.9.108\
>cd C:\temp\pantheios-1.0.1-beta211\build\vc10
>nmake 2>&1 > out.log
c:\temp\pantheios-1.0.1-beta211\bin\ -- тесты
c:\temp\pantheios-1.0.1-beta211\lib\ -- сами библиотеки
c:\temp\pantheios-1.0.1-beta211\include\ -- include файлы
But there are kind people who wrote a utility for choosing the operating modes of the logger, which gives a good clue how to turn this soup set of libraries and headers into a working logger.
Briefly about architecture
The library is actually divided into cheters of the layer:
- Core
- API for applications
- Front end
- Back end
The core is the connecting part of all other parts of the library.
The API for applications is just that set of functions that we can use directly to output to the log in our application.
Front-end - a subsystem responsible for filtering attempts to display messages by logging level.
Back-end is a subsystem that is responsible for outputting messages to a specific recipient (file, console, syslog, etc.), as well as for configuring this recipient (output format for example).
You can read more about architecture on the page: the project itself .
Work testing
We will define the environment variables as follows and run VS2010: Create a standard C ++ Console Project and configure the project so that it can see our library through the environment variables: It's time to start writing the test itself. As we recall, the task was set earlier: output to the log and to the colorful console in UTF-16 simultaneously. For these purposes, you and I must use two Back-Ends: a cosnol and a file. Both the back and front end can be connected to the program using pre-prepared include files. This greatly simplifies the configuration of logging. To further simplify the configuration, a utility was written where you can choose the combination of the necessary headers. You can take it here . Its external interface is quite simple:
>set PANTHEIOS_ROOT=c:\temp\pantheios-1.0.1-beta211\
>set STLSOFT=c:\temp\stlsoft-1.9.108\
>devnev.exe



Actually, the screenshot shows just the options we need.
Briefly explain:
- The Front-end block defines a “simple front-end” - this is the front end “fe.simple” which does not filter anything by the level of logging.
- The back-end block defines the back-end “be.lrsplit”, which splits the incoming message stream into two: file and Windows Console.
The rest, I think, is intuitive.
Ok, now we can copy and fix what the utility generated for us (yes, she made a mistake in choosing be.ltsplit, it’s probably the file where it was renamed that was not taken into account in the utility). We must also supplement the include directly with nuclear.
As a result, we get the following files:
#include
#include
#include
#include
#include
#include
#include
#include
#include
Now we must take into account that fe.simple requires the application name to be additionally defined (for indication in the log file).
To do this, declare a variable:
extern "C" const TCHAR PANTHEIOS_FE_PROCESS_IDENTITY[] = L"MyMegaLogger";
Well, actually now we implement our test:
void testfoo(void*)
{
for(int i=0;i<10;++i)
{
try
{
pantheios::log_DEBUG(TEXT("Привет, русский язык в UTF16?"));
pantheios::log_DEBUG(TEXT("debug"));
pantheios::log_INFORMATIONAL(TEXT("informational"));
pantheios::log_NOTICE(TEXT("notice"));
pantheios::log_WARNING(TEXT("warning"));
pantheios::log_ERROR(TEXT("error"));
pantheios::log_CRITICAL(TEXT("critical"));
pantheios::log_ALERT(TEXT("alert"));
pantheios::log_EMERGENCY(TEXT("EMERGENCY"));
}
catch(std::bad_alloc&)
{
pantheios::log_ALERT(TEXT("out of memory"));
}
catch(std::exception& x)
{
pantheios::log_CRITICAL(TEXT("Exception: "), x);
}
catch(...)
{
pantheios::logputs(pantheios::emergency, TEXT("Unexpected unknown error"));
}
}
}
int _tmain(int argc, _TCHAR* argv[])
{
pantheios::log(pantheios::debug, TEXT("Entering main("),
pantheios::args(argc, argv, pantheios::args::arg0FileOnly), TEXT(")"));
pantheios_be_file_setFilePath(TEXT("local.log"),
PANTHEIOS_BE_FILE_F_TRUNCATE,
PANTHEIOS_BE_FILE_F_TRUNCATE,
PANTHEIOS_BEID_LOCAL);
for(int i=0;i<5;++i){
_beginthread(testfoo, 0, NULL);
}
std::cin.get();
return EXIT_SUCCESS;
}
and get the result:

and similar (but without color) in the local.log file .
Conclusion
We examined the very basic part of the pantheios logger, but it still has a lot of interesting things.
The advantages include speed, unicode support out of the box, cross-platform, type-safe-ing.
Of the minuses, I would single out a rather confusing use procedure and unsupported configuration from a file. However, often, these minuses can be ignored.
Overboard there is a comparison with other loggers, advanced configuration (output format), maybe this will appear in another note.
Thanks to those who read to the end and have a good weekend!