Andreas Wachowski wrote:
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.
I strongly agree with this statement. I once wrote my own logging lib and had both categories and levels. It really helped during debugging/monitoring to be able to focus on different categories at different levels of detail, just by tuning numbers. John's lib looks great and has many advanced features, however I miss this basic functionality. greetings, Roland
-- Andreas
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Roland Weiss - Postdoctoral Researcher - Formal Methods Group WSI-TI, Sand 13, Room 126, University of Tuebingen, 72076 Tuebingen, Germany Tel: +49 7071 2975940 (07071/29-75940) / Fax: +49 7071 29-5062 (07071/29-5062) E-Mail: roland.weiss@uni-tuebingen.de WWW: http://www-ti.informatik.uni-tuebingen.de/~weissr