Boost logo

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
> >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.
> 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
> years.)

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, kalb at, bjorn.karlsson at, gregod at, wekempf at