Boost Users :
From: Mojmir Svoboda (mojmir.svoboda_at_[hidden])
Date: 2008-06-13 03:20:43
* Nat Goodspeed <nat_at_[hidden]> [2008-06-12 10:23:28 -0400]:
> Mojmir Svoboda wrote:
> >no he will _NOT_, that is the beauty ;)) if he still do, let him use
> >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.
> My experience is with large products with many subsystems, worked on by
> many developers over the course of years.
hmm, i've been few years in telco, so i have the picture. blurred may
that one be ;)
> The most effective logging machinery:
> - Allows you to turn on logging at runtime, so your support person in
of course, that is necessary.
> - Has trivial runtime cost for a suppressed log message...
> runtime cost is nothing more than examining a static bool and a jump.
this is related to 1st and i second that.
> - Allows you to be selective about what logging output is produced,
> because if you turn on EVERYTHING, your user has trouble even storing
> and mailing you the resulting file -- never mind your problems trying to
> discover what might be relevant. (This is the result of accumulating
> helpful logging output in many interacting subsystems over the course of
i know, logs can be really huge.
but i never meant to not provide what you call runtime filtering. i
perhaps said something badly. i thought you wanted add another filter at
what i am saying is: User is not allowed to change format of the logged
text at runtime, by changing the formatting chain. i know it can be
done, but i don't want to as i consider it unnecessary.
the reason why is that as you have large codebase with lot of outputs,
your people probably have tools helping them analyse the logs:
regexps, indents, scripts, filters to gnuplot etc etc.
if you change order of the logged columns, your tools are confused.
my approach is simply: think before picking format and then let it be
the same forever (or at least for some long period). as a library user
you can change it during development of course, but to take place, you
have to recompile.
i hope that is clear, now and sorry for confusion i made.
> There are probably people for whom compile-time controls suffice. But
> such a library wouldn't be useful to our developers.
see above: compile-time approach fixes only the order of filters, it does not
disallow runtime filtering.
many thanks for feedback,
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net