Caleb Epstein wrote:
On 4/26/05, Jody Hagins <jody-boost-011304@atdesk.com> wrote:
On Mon, 25 Apr 2005 14:43:57 +0200 John Torjo <john.lists@torjo.com> wrote:
Using the library in code is easy and straightforward:
int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something....";
Along the same lines as other comments, but a little different...
There should be more than one logging variable. You said the above roughly translates to:
if ( is_log_enabled(app) ) app_log() << "testing" << i ...;
However, this restricts the application to one single logging status. I want something like:
if ( is_log_enabled(logvar_foo, app) app_log(logvar_foo) << "testing" << i ...;
which allows the application to have many different logging state objects.
In addition, I think any logging statement should be able to be conditionally compiled away. This should also be based on a value. For example, I should be able to specify on the command line something like: compile away all logging statements below level-x, or compile away all logging statements for domain foo, below level-x.
I guess I am looking for more flexibility. Any logging statement should be able to be compiled away. Any logging statement should be able to check multiple levels against one of many different logging state objects.
I think John's approach to having multiple log "levels" is to just use a separate log for each one (e.g. you might have logs called trace, debug, warning, info, and fatal). Logs are either enabled or disabled; there is no "level" or above-some-threshold-type checking as with some other common implementations.
As far as conditional compilation goes, I think John has agreed to add a new macro that would enclose an entire logging call and could be compiled out of production code.
Further to the statement above and the other replies to this post by Jody and Gennadiy, I would like to add that - in my opinion - categories and levels are two *orthogonal* concepts. Although John's approach works, it gets laborious soon: Suppose I have n categories and m levels, then I need n*m logs with the current approach, but only n categories + m levels when the two aspects are implemented separately. I have to agree that I would appreciate if levels could be added as a distinct feature. -- Andreas