Re: [Boost-users] yet another logging library

From: Mojmir Svoboda (mojmir.svoboda_at_[hidden])
Date: 2008-06-12 07:22:28

hello John,

* John Torjo <john.groups_at_[hidden]> [2008-06-12 12:02:53 +0300]:

> >can you give me some hints in the right direction, please? i mean
> >some general advices "use this if you want be small, this if you want
> >be fast, avoid that at all costs etc". i'd like both, of course.
> >  
> Well, this is quite hard:
> - the locking strategy - make it a policy, which you can change later; 
> this will also make it easy for you to test, using a single threaded app

that is necessary nowadays. i still had no time to do my homework and
explore mt in your code... i will until end of the week.

> - why do you apply filters to the logged text? A filter should be 
> something able to say "yes" or "no" without looking at the text.
>  First of all, if the filter says "no", you shouldn't need to do any 
> processing of the text.

if you are talking about my approach of filters, i mixed three 
concepts according what the user has to do:
 1. nothing at all (filter simply appends text, for example timestamp)
 2. supply an argument - for filters like file, line taking __FILE__ etc
 3. 2. + supply comparation logic and run-time value. this is case
    of levelling logged text and filtering out messages > certain level.

it depends on needs of user and is specified fully by the mpl::vector.
the run-time values of course requires shared access among threads, so
protecting resources has to be done carefully. ordinary mutex is too
much, spinlock fits better.

> - I believe having a compile time vector for formatting the output is a 
> mistake:
>    typedef vector<time, sep, rt_level, sep, file, sep, line<>, sep, fn, 
> sep, msg>::type pipe_mania;
>   The user should be able to specify that at runtime - what if he wants 
> to configure the log at runtime?

no he will _NOT_, that is the beauty ;)) if he still do, let him use log4jpp.
according to my (i admit that short perhaps) experiences, this is very
rarely needed.
you can either modify source and recompile or use log4j++ like i said.

for really simple filtering you can always use levels, context (i call
that some "logic areas" of code like data flow, system message passing, 
etc), threadids, etc. ie simple cases already built in the chain at the 
compile-time. the run-time filtering logging facility should be really stupid
and fast. no regexps etc.

but more refined filtering for human analysis can be done by some external
tool and that is where i aim to:
 1. you configure your logging and you don't really pay what you dont
    use
 2. you compile your application
 3. run it
 4. (optional) configure your run-time filtering values like level
 5. stop the program and grab the text
 6. analyse the text in some tool
    this tool colorizes thread ids, perform some regex replacements, 
        ...whatever
        in my case it's mighty AWK, dog bless that thingy.

> Other than that, I need to see more docs about what you're going to 
> implement.

basic logging facilities. logger, some accessor (singleton?),
simple appenders, few run-time filters and few sinks (file/socket).

> Oh well, I don't care that much about size nowadays.

oh my goth, aren't you one of THEM? :) i'm thinking myself lately that
this is kind of black plague of c++...

> > - pthreads are detected incorrecty. even in singlethr model mutex
> >    is required.
> What do you mean?

i did not use bjam for the build as i really think this tool surely
comes from hell. my line is simple:
g++ -I ~/devel/boost -I ~/devel/logging/ aa1.cpp

but your code incorrectly detects presence of -pthread (/MT on msvc i
think) switch and includes some code using pthreads even if -pthread 
is not present.
i don't remember exactly, but $BOOST_ROOT/boost/config/...stuff..
makefiles do that for you and sets BOOST_HAS_THREADS correctly.

perhaps i am wrong and it is bjam who is doing that.

best regards,
mojmir