logog: logger optimized for games

High performance. It is possible to disable all logging functionality entirely within logog. In this case logog incurs zero performance penalty on executing code. All logging functions compile to no-ops in the case where the logging level is set to disabled. When logging is enabled, the do-not-log control path requires exactly one boolean comparison. All performance-critical operations have been constructed to have constant time or near constant time performance. logog was designed to assume that no memory or CPU time is available for logging on a final release build of software. When compiling in final release mode, logog is designed to compile completely away -- zero memory allocations, zero CPU cycles spent.

Logging to arbitrary destinations. Log messages can be sent to stdout, stderr, a log file or into memory, or any combination of these. Logging classes are highly extensible, so logging to new destinations is easy to add.

Multiple simultaneous logging criteria. Messages can be simultaneously logged to different log targets with different requirements: by file, by category, by log level, or by group. Substring matching permits regexp-like behavior on logging criteria.

Limited external dependencies. logog only requires a reasonably modern standards-compliant C++ compiler (tr1 or later). logog has limited dependencies on STL. Those dependencies have been orchestrated to mitigate the negative performance impacts of the STL. Additionally, those dependencies have been abstracted into macros so that STL can easily be replaced with a somewhat compatible template library of your own choosing.

Highly granular control over which message types are logged. Control over these messages may be determined at compile-time for maximal performance, or at run-time for interactively enabling or disabling log message types during execution. Messages may be logged by source file, group, category, or message contents.

Support for advanced logging requirements. logog's pub-sub architecture means that logging can occur simultaneously to multiple log targets, each with its own logging criteria. Stable base classes permit new logging targets to be easily added.

Extremely configurable memory usage and policy. All memory allocations happen after initialization time via a user-supplied memory manager (or the default std::allocator). In other words, you can configure ALL memory allocations to occur from custom malloc() and free() style functions of your own authorship.

All allocated memory is freed after the shutdown -- logog does not leak memory. A special compilation flag (LOGOG_LEAK_DETECTION) audits every allocation and free within logog to discover and fix memory leaks therein.

Support for POSIX-type and Windows-type operating systems. The logog system has been tested under: 32 and 64-bit Windows (compiled with VS2008); Cygwin 1.7.0; and 64-bit Ubuntu Linux 10.04 LTS. Support for proprietary game consoles is implicit or latent; the system has been demonstrated to work on Xbox 360 and PS3 (with certain proprietary header files). Support for other OSes is straightforward; all OS dependencies are encapsulated in macros.

Support for multithreading. Multiple thread sources are permitted to send logging messages at the same time.

Support for re-entrancy. If triggering a log message indirectly causes another log message to be triggered, either through the memory allocator or some other user-based policy, logog is not permitted to hang in a multithreaded environment.

Unicode (wide-character) support for all strings; define LOGOG_UNICODE and all strings go from char-based to wchar-based.

Verbose documentation. By far the best documented logging system available. logog uses doxygen comments throughout.

Extremely permissive license. logog is released under the MIT License, so it may be used freely in commercial as well as open-source projects, with proper attribution to logog's authors (Gigantic Software).