Clutchlog is a logging system that targets versatile debugging. It allows to (de)clutch messages for a given: log level, source code location or call stack depth.
@@ -118,13 +119,13 @@ ExampleFor more detailled examples, see the "API documentation" section below and the tests directory.
For more detailled examples, see the "Usage" sections below and the tests directory.
Most of existing logging systems targets service events storage, like fast queuing of transactions in a round-robin database. Their aim is to provide a simple interface to efficiently store messages somewhere, which is appropriated when you have a well known service running and you want to be able to trace complex users interactions across its states.
-Clutchlog, however, targets the debugging of a (typically single-run) program. While you develop your software, it's common practice to output several detailled informations on the internal states around the feature you are currently programming. However, once the feature is up and running, those detailled informations are only useful if you encounter a bug traversing this specific part.
+Clutchlog, however, targets the debugging of a (typically single-run) program. While you develop your software, it's common practice to output several detailled informations on the internal states around the feature you are currently programming. However, once the feature is up and running, those detailled informations are only useful if you encounter a bug traversing this specific part.
While tracing a bug, it is tedious to uncomment old debugging code (and go on the build-test cycle) or to set up a full debugger session that displays all appropriate data (with ad-hoc fancy hooks).
-To solve this problem, Clutchlog allows to disengage your debug log messages in various parts of the program, allowing for the fast tracking of a bug across the execution.
+To solve this problem, Clutchlog allows to disengage at runtime your debug log messages in various parts of the program, allowing for the fast tracking of a bug across the execution.
The default log format is "[{name}] {level_letter}:{depth_marks} {msg} {hfill} {func} @ {file}:{line}\n", it can be overriden at compile time by defining the CLUTCHLOG_DEFAULT_FORMAT macro.
By default, and if CLUTCHLOG_DEFAULT_FORMAT is not defined, clutchlog will not put the location-related tags in the message formats (i.e. {name}, {func}, and {line}) when not in Debug builds.
The default format of the first line of comment added with the dump macro is "# [{name}] {level} in {func} (at depth {depth}) @ {file}:{line}". It can be edited with the format_comment method. If it is set to an empty string, then no comment line is added. The default can be modified at compile time with CLUTCHDUMP_DEFAULT_FORMAT.
By default, the separator between items in the container is a new line. To change this behaviour, you can change CLUTCHDUMP_DEFAULT_SEP or call the low-level dump method.
By default, and if CLUTCHDUMP_DEFAULT_FORMAT is not defined, clutchlog will not put the location-related tags in the message formats (i.e. {file} and {line}) when not in Debug builds.
The mark used with the {depth_marks} tag can be configured with the depth_mark method, and its default with the CLUTCHLOG_DEFAULT_DEPTH_MARK macro:
The character used with the {hfill} tag can be configured wth the hfill_mark method, and its default with the CLUTCHLOG_DEFAULT_HFILL_MARK macro:
Clutchlog measures the width of the standard error channel. If it is redirected, it may be measured as very large. Thus, the hfill_max accessors allow to set a maximum width (in number of characters).
Note: clutchlog will select the minimum between hfill_max and the measured number of columns in the terminal, so that you may use hfill_max as a way to constraint the output width in any cases.
By default, clutchlog removes 5 levels of the calls stack, so that your main entrypoint corresponds to a depth of zero. You can change this behaviour by defining the CLUTCHLOG_STRIP_CALLS macro.
The output can be colored differently depending on the log level.
The default format of the first line of comment added with the dump macro is "# [{name}] {level} in {func} (at depth {depth}) @ {file}:{line}". It can be edited with the format_comment method. If it is set to an empty string, then no comment line is added. The default can be modified at compile time with CLUTCHDUMP_DEFAULT_FORMAT.
By default, the separator between items in the container is a new line. To change this behaviour, you can change CLUTCHDUMP_DEFAULT_SEP or call the low-level dump method.
By default, and if CLUTCHDUMP_DEFAULT_FORMAT is not defined, clutchlog will not put the location-related tags in the message formats (i.e. {file} and {line}) when not in Debug builds.
The mark used with the {depth_marks} tag can be configured with the depth_mark method, and its default with the CLUTCHLOG_DEFAULT_DEPTH_MARK macro:
The character used with the {hfill} tag can be configured wth the hfill_mark method, and its default with the CLUTCHLOG_DEFAULT_HFILL_MARK macro:
Clutchlog measures the width of the standard error channel. If it is redirected, it may be measured as very large. Thus, the hfill_max accessors allow to set a maximum width (in number of characters).
Note: clutchlog will select the minimum between hfill_max and the measured number of columns in the terminal, so that you may use hfill_max as a way to constraint the output width in any cases.
By default, clutchlog removes 5 levels of the calls stack, so that your main entrypoint corresponds to a depth of zero. You can change this behaviour by defining the CLUTCHLOG_STRIP_CALLS macro, or calling strip_calls.
By default, clutchlog is always enabled if the NDEBUG preprocessor variable is not defined (this variable is set by CMake in build types that differs from Debug).
You can however force clutchlog to be enabled in any build type by setting the WITH_CLUTCHLOG preprocessor variable.
Note that allowing a log level does not mean that it will actually output something. If the configured log level at runtime is lower than the log level of the message, it will still not be printed.
This behavior intend to remove as many conditional statements as possible when not debugging, without having to use preprocessor guards around calls to clutchlog, thus saving run time at no readability cost.
-All configuration setters have a getters counterpart, with the same name but taking no parameter, for example:
To control more precisely the logging, one can use the low-level log method:
A similar dump method exists:
You can access the identifier of log levels with level_of:
The CLUTHFUNC macro allows to wrap any function within the current logger.
For instance, this can be useful if you want to (de)clutch calls to asserts. To do that, just declare your own macro:
Thus, any call like ASSERT(x > 3); will be declutchable with the same configuration than a call to CLUTCHLOG.
The CLUTCHCODE macro allows to wrap any code within the current logger.
For instance:
Here what you would do to setup clutchlog with the default configuration:
To use clutchlog, just include its header in your code and either ensure that the NDEBUG preprocessor variable is not set, either define the WITH_CLUTCHLOG preprocessor variable.
If you're using CMake (or another modern build system), it will unset NDEBUG —and thus enable clutchlog— only for the "Debug" build type, which is usually what you want if you use clutchlog, anyway.