Main Page | Namespace List | Class Hierarchy | Alphabetical List | Class List | File List | Namespace Members | Class Members | File Members

Overview

0.5

Version:
templog 0.6
Author:
Hendrik Schober
Date:
2007-03-02

Introduction

The templog logging library is designed with (portable) efficiency being the most important goal. In order to achieve this, it relies on template meta programming and inlining to allow filtering of log messages at compile-time. Also, log messages use lazy evaluation to allow efficient run-time filtering of those log messages that aren't weeded out at compile-time.

The second most important goal was ease of use. Therefor log messages can be created using the stream idiom.

Loggers

In order to log messages using the templog library it's necessary to first to define a logger. A logger is an instance of the logger template which forwards log messages. Each logger is passed (by way of template parameters) a minimum severity and a list of audiences. Log messages passed to a logger with a severity less than the logger's severity or with a targeted audience which is not in the logger's audience list will be dropped by the logger at compile-time.

Each logger instance is passed (also by way of a template parameter) another logger instance to which, after applying the above mentioned filtering, it forwards its log messages. That instance, after applying filtering according to its minimum severity and its audience list, in turn forwards its log messages to some other logger instance. Several loggers can forward to the same other logger, so that loggers form a direct, acyclic graph.

Formatting and write policies

At the root of the resulting logger hierarchy always is a non_filtering_logger which uses a formatting policy (see formatting_policy_base, passed as a template argument) to format log messages and a write policy (see write_policy_base, also passed as a template argument) to write them to some log message sink. Write policies have a meta function writes which can be used to globally filter log messages at compile-time and a is_writing() static member function that can be used to globally filter log messages at run-time.

There are several predefined formatting and write policies. There are also default policies (see std_formating_policy and std_write_policy) and a type global_logger using these which can be used as the root of a logging hierarchy. User-defined loggers can directly or indirectly forward their log messages to this global logger:

  typedef templog::logger< templog::global_logger
                         , templog::sev_info
                         , templog::audience_list<aud_developer,aud_support,aud_user> >
                                                    myModuleLogger;
  typedef templog::logger< templog::myModuleLogger
                         , templog::sev_message
                         , templog::audience_list<aud_support> >
                                                    mySupportLogger;
  typedef templog::logger< templog::myModuleLogger
                         , templog::sev_message
                         , templog::audience_list<aud_user> >
                                                    myUserLogger;

The TEMPLOG macro

In order to log a message using a logger, a log_forwarder obtained from that logger must be assigned a compile-time list of log_intermediate instances referring to the log parameters. An easy way to do this is using the TEMPLOG_LOG macro, passing the logger, the log message's severity, and its intended audience. The result of that macro invocation can be streamed into using the common ostream operators. For example, this
  TEMPLOG_LOG(mySupportLogger,sev_debug,aud_support) << "x = " << x;
uses the logger mySupportLogger to log a message with the severity sev_debug, and the targeted audience aud_support that consists of the string "x = " and the value of x. Note that, according to its definition, the logger mySupportLogger will drop this log message, because sev_debug is below its minimum severity sev_message.

Turning logging volume up or down

If loggers are created so that their hierarchy resembles a software system's architecture, it is rather easy to either quieten the logging behaviour of whole parts of the system through restricting loggers' filtering, or alternatively make parts of the systems log more verbosely by removing restrictions from their loggers (and, if necessary, have them forwarding directly to the global_logger, so that their log messages won't be discarded by intermediate loggers).

See also:
logger

global_logger

formatting_policy_base

write_policy_base

std_formating_policy

std_write_policy


Generated on Sun Jan 11 15:57:20 2009 for templog library by  doxygen 1.4.2