GoodLog: A Lightweight C++17 Wrapper Around Boost.Log

SoleyRan — Sun, 03 May 2026 16:21:01 +0000

I recently cleaned up and published a small C++ logging component called GoodLog.

It is not meant to replace full logging frameworks. Instead, it wraps the parts of Boost.Log that I kept reusing in C++ projects: colored console output, rotating log files, severity filtering, source location, and hex dump helpers for binary buffers.

GitHub:

https://github.com/SoleyRan/Log

Why I Built It

Boost.Log is powerful, but setting it up repeatedly can get verbose.

In many C++ modules, I usually want the same basic behavior:

write readable logs to the terminal
keep rotated log files on disk
filter console and file output separately
include the source file and line number
dump binary buffers while debugging protocols or middleware messages

The application code should stay simple:

goodlog::logInit("/tmp/goodlog/", 2, 1, 10, 10);

LOG_Debug() << "debug details";
LOG_Info()  << "service started";
LOG_Warn()  << "using fallback config";
LOG_Error() << "connection failed";

GoodLog is my attempt to keep Boost.Log as the backend while exposing a smaller interface for everyday use.

What GoodLog Supports

Currently, GoodLog provides:

C++17
Boost.Log based implementation
trace, debug, info, warning, error, and fatal levels
automatic file:line source location
colored terminal output
rotating file sink
separate severity thresholds for console and file logs
optional channel filtering
hex dump helpers for binary buffers
CMake build
demo and GoogleTest entry points

Here is a terminal preview:

Quick Start

git clone https://github.com/SoleyRan/Log.git
cd Log
cmake -S . -B build
cmake --build build
./build/demo/log_demo

By default, the demo writes rotated log files under:

/tmp/goodlog/

Basic Usage

#include <log.hpp>

int main()
{
    const std::string log_path = "/tmp/goodlog/";
    const int console_log_level = 2; // info and above
    const int file_log_level = 1;    // debug and above
    const int max_log_size_mb = 10;
    const int max_log_files = 10;

    goodlog::logInit(
        log_path,
        console_log_level,
        file_log_level,
        max_log_size_mb,
        max_log_files
    );

    LOG_Debug() << "debug details";
    LOG_Info()  << "service started";
    LOG_Warn()  << "using fallback config";
    LOG_Error() << "connection failed";
    LOG_Fatal() << "unrecoverable error";

    return 0;
}

Output Format

GoodLog formats each record with timestamp, severity, source location, and message:

[2026-05-02 10:24:18.123456]<info>[main.cpp:18]:service started
[2026-05-02 10:24:18.123789]<warning>[main.cpp:19]:using fallback config
[2026-05-02 10:24:18.124000]<error>[main.cpp:20]:connection failed

Log files use a sortable counter and timestamp pattern:

00000-2026-05-02-10-24-18.log
00001-2026-05-02-10-27-42.log

Severity Configuration

console_log_level and file_log_level control the minimum severity for terminal output and file output.

Value	Severity
`0`	trace
`1`	debug
`2`	info
`3`	warning
`4`	error
`5`	fatal

For example:

goodlog::logInit("/tmp/goodlog/", 2, 1, 10, 10);

This means:

console output keeps info and above
file output keeps debug and above
each log file can grow up to 10 MB
up to 10 log files are retained

This keeps terminal output relatively clean while preserving more details in files.

Hex Dump Helpers

GoodLog also includes helpers for inspecting binary data.

This is useful when debugging network packets, sensor data, custom protocols, or middleware messages.

std::array<unsigned char, 4> payload = {0x12, 0x34, 0xab, 0xcd};

LOG_DEBUG_HEX(payload.data(), payload.size(), "rx payload");

Why Keep Boost.Log Underneath?

I did not want to reimplement a logging system from scratch.

Boost.Log already has a mature model for sinks, formatters, severities, asynchronous logging, and file backends. GoodLog is more of a practical wrapper: it keeps the backend and makes the common setup easier to reuse.

When It Might Be Useful

GoodLog may be useful for:

C++ services
middleware modules
robotics or autonomous-driving related tools
debugging-heavy native applications
projects that already depend on Boost
applications that inspect binary protocols or sensor data

If you need a dependency-free logger, a package-manager-ready public library, or a fully hardened production logging framework, GoodLog still needs more work.

Project Layout

.
|-- CMakeLists.txt
|-- demo/
|   `-- log_demo.cpp
|-- src/
|   |-- log.hpp
|   |-- text_file_backend_self_defined.cpp
|   `-- text_file_backend_self_defined.hpp
`-- test/
    `-- log_test.cpp

Roadmap

Next steps I want to improve:

better CMake install/export targets
Ubuntu CI
more complete integration examples
channel macro namespace cleanup
more tests

GitHub