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?
a unique ID (variable). Something like: boost::logtl::unique_id activity_logid; and #define LOG(x) if (!is_enabled_log(x##_logid)) ; else x or something like it ;)
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.
of course, it'll be easy to add filtering/prefixing (timestamp,etc.).
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 ;-)
Got that right :D Best, John