Logfault v0.8.5 is released
Over the years, logfault has become my personal workhorse when it comes to logging from C++. I use it in all the projects I’m actively working on.
Why logfault Exists
I originally wrote logfault because I needed a practical solution to a very specific problem: I was developing a C++ library for iOS and Android, while doing most of my development under Linux. I wanted to use the same log statements everywhere, but have them routed to the correct logging facilities on each platform.
At the time, I found no open source logging libraries that fit that use-case. So I wrote my own.
What started as a small utility slowly evolved as my needs grew.
Built for Convenience, Not Microbenchmarks
logfault is not the fastest C++ logging library in existence—and that’s by design. There are excellent libraries out there that win on raw performance. logfault focuses instead on:
- Ease of use
- Consistent behavior across platforms
- Predictable output
- Developer convenience
For most real-world applications—client apps, mobile apps, backend servers, or microservices—this tradeoff has proven more than worth it.
Flushes the log after each log-message
When I used Boost.Log, I experienced that unless internal buffers filled up, nothing appeared. While debugging, this is incredibly frustrating.
With logfault, output appears immediately.
That means I can:
- Follow logs in real time in less or tools like
glogg - See exactly what my application is doing as it happens
Whether I’m debugging a mobile app, a client application, or a backend service, that immediacy matters.
A More Careful Release This Time
In the past, I’ll admit I was sometimes a bit too optimistic. I made changes, cut a release—and only later discovered that something broke on a different architecture, like ARM.
After the latest round of changes, I waited a couple of months before calling it a stable release. I tested across platforms, looked for red flags, and made sure everything behaved as expected.
And today—January 2nd—it came up on my todo-list in my personal organizer, NextApp.
🎉 Happy New Year, by the way. 🎉
Stable Release: January 2nd
As planned, I’ve now released a new stable version of logfault. Everything appears to be working reliably across platforms, with no unpleasant surprises so far.
So: happy coding in 2026.
Should You Use logfault?
logfault isn’t just convenience — it’s practical engineering. If you’re writing portable C++ code that needs reliable, flexible logging across multiple platforms, you might find logfault useful.
✅ What Makes logfault Stand Out
Header-only, no heavy dependencies logfault is a header-only C++ library that doesn’t pull in any heavy dependencies other than the standard library and native platform log systems. That makes it very easy to integrate into projects without build system complexity.
Cross-platform logging support It supports logging to:
- Std::ostream (console or file)
- syslog and systemd journal on Linux
- Android logcat
- Apple unified logging (os_log)
- Qt logging macros
- Windows EventLog
This lets your library or app use the same logging calls everywhere without platform-specific code.
Flexible and modern log handling logfault comes with built-in handlers, including a JSON output handler, which makes logging easy to parse with log aggregators or cloud observability tools.
Efficient when it matters Log events are:
- Lazy evaluated — log expressions aren’t processed unless they meet the configured log level.
- Compile-time filtered — you can entirely remove verbose log levels (like TRACE) from release builds.
This means logfault pays only for what you use in production while giving you rich diagnostic output in development.
Always flushed output (optional) Like I mentioned earlier — and also supported in the library — logfault can flush every log message, giving you up-to-the-moment logging during tests and debugging. (You can also disable this for better performance when needed.)
⚠️ When It Might Not Be the Best Fit
logfault isn’t designed to replace performance-tuned logging libraries in scenarios where massive log volume and extreme throughput are critical (e.g., ultra-high-performance trading systems). Because it builds on std::ostream and platform facilities, raw throughput won’t match the fastest buffer-oriented loggers.
📌 TL;DR — Use logfault If…
You want a portable, easy to integrate, flexible logging foundation for:
- Mobile and IoT projects
- Cross-platform C++ projects
- Backends and microservices where readability and structure (like JSON logs) matter
- Scenarios where debugging visibility and simplicity outweigh raw logging throughput
Full disclosure: This article was formatted and edited by AI from an audio transcript