John Torjo wrote:
I think that hierarchical loggers ala log4j are necessary.
Yes, they are, and I will certainly implement them. Each type of log will have a unique internal ID, by which you use it within your program (example: LOG(activity) << "blabla")
What's "activity"? Is that variable?
and a string associated with it (example: "app.activity").
Based on this hierarchy the message will be forwarded to a certain function. Also, enabling/disabling of logs can happen like this: logs().disable( "*.warn.*"); // disable all warning messages
Ok, that's fine.
that to write a custom function do to the same. Further, with a custom function you cannot customize the processing chain from config file.
you can do basically anything with a custom function (if you wish:D) As with the config file, if anyone wants to specify processing chain in a config file, they will implement it on top of my log library. I don't intend to provide working with a config file from the log library - that would be too much coupling.
I meant something different. Customizing things from config file is much easier if you have fine-grained building blocks -- for adding timestamp, for some filtering, for adding to file. If library does not provide such building blocks, it's usability will be very limited.
Besides, I think configuring loggers from config file is a very good thing, too.
Yes, me too (mostly enabling/disabling). But, you should use another library to read from the config file (for instance: Persisting Settings Library (http://builder.com.com/5100-6370-5157525.html?tag=sc)), and then specify the logging options.
Well, I can use the program_options library for that ;-) - Volodya