Feature Map

Feature Map

This page maps common logging-library terms to the way the same capability is implemented in logme.

The goal is discoverability. Some logme features intentionally live at a different layer than similarly named features in other libraries. For example, logme does not need a NullBackend to represent discarded output, and repetition control is not implemented as a backend-side duplicate filter.

---

Quick map

Common capability	logme mechanism	Main code areas	Related pages
Null sink / null backend	A channel with no backends, combined with early precheck	Channel, Precheck, logging macros	Why logme is fast, Precheck example
Sink-level filtering	Channel-level level/filter checks by design	Channel, Routing, OutputFlags	Core Concepts, Routing, Message Filtering
Duplicate suppression	_Once macros and override repetition limits	Logme.h, Override.h, Override.cpp	Override Scopes, OneTime example
Rate-limited logging	_Every(ms) macros and override frequency limits	Logme.h, Override.h, Override.cpp	Advanced Features, OnceEvery example
Rotating file sink	FileBackend size control, daily rotation, and part cleanup	FileBackend, FileBackendConfig, file IO classes	File Backend, File Rotation & Retention
Total log directory size control	DirectorySizeWatchdog on the logger home directory	DirectorySizeWatchdog, Logger	File Rotation & Retention, Configuration JSON
Runtime backend management	Control API commands, logmectl, and logmeweb	Control/Command, logmectl, logmeweb	Runtime Control, Control Server, logmectl, logmeweb
Custom sink / appender	Derive from Logme::Backend and implement Display(Context&), or use CallbackBackend for a function-based sink	Backend.h, CallbackBackend	Custom Backends, Backends
Structured sink output	Channel output flags select text, JSON, or XML rendering	OutputFlags, Context, format code	Structured Logging, OutputFlags
Recent-history capture	RingBufferBackend	RingBufferBackend	Buffer Backend
Windows Event Log output	WindowsEventLogBackend	WindowsEventLogBackend, WindowsEventLogManager	Backends, Configuration JSON
Temporary in-memory output	BufferBackend	BufferBackend	Buffer Backend
Production dormant trace sites	Trace points	TracePoint, trace macros, control commands	Trace Points, TracePoints example

---

Implemented differently on purpose

No separate NullBackend

logme does not need a dedicated null backend. If a channel has no backends and no active routes that can receive the record, the logging path can reject the message early. That is cheaper and simpler than constructing a backend object whose only job is to discard records.

This is especially important for benchmark and production scenarios where logging calls remain compiled in, but no output is currently requested.

Channel-level filtering instead of backend-level routing

In logme, a channel is the unit of logging policy. The channel has its level, flags, routing links, subsystem policy, and backend list.

This is intentional. Fast rejection happens before formatting and before backend delivery. Adding per-backend level routing to the hot path would require checking backend policy during message acceptance and would weaken the channel-as-a-policy-unit model.

If different outputs need different policies, the logme model is to use separate channels or explicit routing, not hidden backend-level filters.

_Once and _Every instead of a duplicate-filter sink

Some libraries implement duplicate suppression as a sink wrapper. logme implements repetition and frequency control at the call site through _Once, _Every(ms), and override helpers such as LOGME_ONCE4THIS, LOGME_EVERY4THIS, LOGME_ONCE4CALL, and LOGME_EVERY4CALL.

This keeps the decision close to the log statement and can reject repeated messages before formatting, routing, or backend delivery.

File rotation is part of FileBackend

logme does not expose file rotation as a separate sink type. The production file behavior is built into FileBackend and related file-management code.

The file backend supports size control, daily rotation, part retention, append behavior, and cleanup of rotated parts. The logger home directory can additionally be protected by DirectorySizeWatchdog, which limits total disk usage across matching files.

---

Remaining backend gaps

The following backend families are common in logging ecosystems but are not currently built-in logme backend types:

• SyslogBackend for Unix/Linux syslog integration
• SystemdJournalBackend for systemd services
• AndroidLogBackend / logcat backend for Android NDK projects
• optional network log streaming backend, if logme should provide native TCP/UDP/TLS log forwarding

CallbackBackend and WindowsEventLogBackend are now built-in backend types. They are backend additions, not replacements for the existing channel, filtering, override, runtime-control, or file-management model.