My name is Kjell Hedstrom and I'm the author and primary maintainer of this project you've stumbled upon or maybe used for a long time. For over a decade, I’ve been dedicating my free time to this open-source initiative, while also refining my skills in various languages like **C++**, **Python** and Java - with some playful hobby endeavors in **Kotlin**, **Go**, and **Rust**.
Given the current job market scenario, I'm actively seeking **Senior Engineering roles** as well as **contract opportunities**. If you or someone you know could benefit from my expertise and contributions – or if you'd be interested in supporting further development of this open-source project through a professional partnership – please don't hesitate to reach out!
You can contact me directly at Kjell@TasteOfTheWoods.com or connect with me on [linkedin.com/in/kjellkod](https://www.linkedin.com/in/kjellkod/). If you wish to get a grasp of my capabilities, commitment, and what I could bring to your team, please do check out the recommendations on my [LinkedIn recommendations](https://www.linkedin.com/in/kjellkod/details/recommendations/) profile. These are from previous managers, colleagues, and direct reports - individuals who have worked alongside me and experienced first-hand the quality of my contributions.
Thank you very much for your time and for considering me for opportunities. I look forward to possibly working together to create something great!
For more in-depth information please see the full usage description in [g3log.md](docs/g3log.md). The internal API for more advanced integration with g3log can be accessed in [API.md](docs/API.md)
CHECK_F(less > more, "CHECK(false) will trigger a fatal message")
```
## 5. Handling of fatal
By default g3log will capture fatal events such as `LOG(FATAL)`, `CHECK(false)` and otherwise fatal signals such as:
```
SIGABRT
SIGFPE
SIGILL
SIGSEGV
SIGTERM
```
When a fatal event happens the not-yet written log activity will be flushed to the logging sinks. Only when all logging activity up to the point of the fatal event has happend, will g3log allow the fatal event to proceed and exit the process.
If `object` symbols are available the fatal handler will attempt to push the stacktrace up to the fatal reason to the logging sink.
#### 5b. Overriding and customization of fatal event handling
The default logging levels are `DEBUG`, `INFO`, `WARNING` and `FATAL`. You can define your own logging levels or completely replace the logging levels. Ref: [API.md](docs/API.md)
in the configuration. See the [API.md](docs/API.md) for information. Log filtering can also be handled through the sink as can be seen in [github/Kjellod/g3sinks](https://github.com/KjellKod/g3sinks)
The default logging sink has no external 3rd party dependencies. For more logging sinks please see [github/Kjellod/g3sinks](https://github.com/KjellKod/g3sinks)
With the default application name left as is (i.e. "g3log") a creation of the logger could look something like this:
```cpp
const std::string directory = "./";
const std::string name = "TestLogFile";
auto worker = g3::LogWorker::createLogWorker();
auto handle = worker->addDefaultLogger(name, directory);
```
The resulting filename would be something like:
```
./TestLogFile.g3log.20160217-001406.log
```
## <a name="performance">Performance</a>
G3log aims to keep all background logging to sinks with as little log overhead as possible to the logging sink and with as small "worst case latency" as possible. For this reason g3log is a good logger for many systems that deal with critical tasks. Depending on platform the average logging overhead will differ. On my 2010 laptop the average call, when doing extreme performance testing, will be about ~2 us.
The worst case latency is kept stable with no extreme peaks, in spite of any sudden extreme pressure. I have a blog post regarding comparing worst case latency for g3log and other loggers which might be of interest.
You can find it here: https://kjellkod.wordpress.com/2015/06/30/the-worlds-fastest-logger-vs-g3log/
The g3log repository is evaluating both github actions and CircleCI for executing test coverage, installation and document generation. For windows the repo is still relying on appveyor. In case you want to look into change any of these setups the following files are the ones of interest.
If you like this logger (or not) it would be nice with some feedback. That way I can improve g3log and it is always nice to hear when and how someone is using it.
If you have ANY questions or problems please do not hesitate in contacting me at
`Hedstrom @ Kjellod. cc`
# <a name="say-thanks">Say Thanks</a>
This logger is available for free and all of its source code is public domain. A great way of saying thanks is to send a donation. It would go a long way not only to show your support but also to boost continued development.
