From: Richard Day (richardvday_at_[hidden])
Date: 2007-04-05 07:32:04
Michael Lacher wrote:
> The way I see it there are two different things you need to consider
> when talking about pleasing everyone:
>
> 1) What can the logging library actually do. This includes the filtering
> possibilities, amount/types of sinks already included, extensibility, ...
>
> I think its pretty straightforward how to actually implement channels,
> sinks, ... and therefore most logging libraries supporting these
> features will have a very similar design.
>
> 2) How to use the logging library. This includes the setting up of the
> logging, and the actual logging itself. The setup is only done once, so
> if it requires many API calls and can get somewhat complicated (if you
> use any special features) it doesn't really matter. But log calls
> themselves will actually number in the thousands. This is what i look
> for first when looking at a logging library:
>
> Can I write a log message that logs what i want, when i want it and in
> the format i want it in a way thats easy and still looks sane ?
>
> If this criteria is not fulfilled I would not use the library under any
> circumstance and I guess many users will think similar. As an example
> that was used earlier in this list:
>
> logger << lazy(lambda::var(x) + ":" + y, _level = mpl::int_<2>());
>
> Imho it is neither immediately apparent what this actually does (maybe
> to boost and C++ gurus it is) nor would i want to write something like
> this every time i log something.
>
> Michael Lacher
>
>
I agree completely. I have no idea what that does either. I could
speculate but theres no point.
My needs would be both stream and macro logging.
I need macro's for turning it off for release builds for example.
Stream for general logging purposes.
As far as configuration goes I believe some minimal support should be
included such as reading in a specified text file but nothing more
extravagant.
If people want XML/Registry etc support it should be easy to add though.
I am completely against automatic configuration. It should definitely be
code initialized.
Simple examples.
DBG_LOG( "Null pointer we are now dying a hard death" );
vs
logger << CLASS_WARNING << "File not found : " << filename << endl;
With two completely different in many respects requirements satisfying
everyones needs is the issue.
Richard Day