Is it? The basic idea is (1) to have functional object to do the logging (2) allow to form chain of responsibility pattern from individual objects to make the system for flexible.
this can be implemented within the log function, if it's really necessary. I don't see why it would need to be too formal.
Here's how I see it: 1. Given a log level, the user gets hold of the corresponding boost::logger and tries to output something.
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") 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
2a. If that log is disabled, nothing else happens. 2b. If that log is enabled, the message to be outputted is written to a stringstream, then converted to a string.. The function corresponding to its level is called. That's it!
What I propose is that this function can forward the request (after some processing) to other functions. In other words, you focus on front-end interface while I talk about inner workings.
yes
If you want formatter (your step 5.) or prefix (your step 4.), you can simply do them in your custom function.
It simpler (IMO) to write
syslog_appender sl; file_appender fl; timestamp_adder t; t.message.connect(sl); t.message.connect(fl); your_logger.message.connect(timestamp);
haven't used boost::signals before, but I guess I know what you mean. I'll definitely think about 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.
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. Best, John
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost