Logging Library over Iostreams? (was Logging Library -- Formal Review Request)
On Behalf Of Darryl Green Hi John,
John Torjo <john.lists <at> torjo.com> writes:
I've seen that some of you have requested "levels", and yes, I
should
add them. I hope I'll have time to implement them soon (less than a month).
However, it probably isn't general or clean enough an interface, and this could be addressed by providing a concept something like the following, to replace the (not customisable at present) logger_impl.
struct sink { void write(const log_types::stream &s); bool enabled(log_types::level l); };
The rest of the interface (actual type) is log_manager defined. A sink with the current semantics + level support implemented by extending the enabled flag to be a level (something you previously talked me out of, but [Brian Braatz Writes:] This thread is making me contemplate,
Why not make this logging library a well designed bolt on to IOSTREAMS? I LOVE IOSTREAMS, and it seems like if the logging library is (DESIGNED TO BE) an add on to that I get the best of both worlds.
Brian Braatz <brianb <at> rmtg.com> writes:
On Behalf Of Darryl Green struct sink { void write(const log_types::stream &s); bool enabled(log_types::level l); };
The rest of the interface (actual type) is log_manager defined. A sink with the current semantics + level support implemented by <snip> [Brian Braatz Writes:] This thread is making me contemplate, Why not make this logging library a well designed bolt on to IOSTREAMS? I LOVE IOSTREAMS,
I won't be buying that particular t-shirt myself, but whatever...
and it seems like if the logging library is (DESIGNED TO BE) an add on to that I get the best of both worlds.
Streams do formatting, streambufs do buffering (or not) and interface to the actual I/O um - channel (to avoid overloading stream :-), including character code conversion stuff. You can use a stream to do the log message formatting (ie. if log_types::stream is, as it is in the default case, an ostringstream). You can write an appender that puts the string straight into a streambuf, there is no formatting to do, only a (possible) code conversion. In what way isn't this a "well designed bolt on to IOSTREAMS"? I can see is that it is more general than is necessary if one takes the view that iostreams provide all the facilities/customisation points you could need. I'm not of that view. The various customisation types used in the lib are perhaps named too closely to their default types making it a little obscure how they can be used. log_types::stream could be called log_types::msg_builder log_types::string could be called log_types::msg That is, the logging lib simply requires that there is a type that will build a message from - well - whatever you want and that there is a way of getting the built message from it. The message is what appenders receive. A structured message format might be appropriate for some uses. In this case, more/all of the formatting would be pushed to the appenders (or to the viewer). This doesn't involve any use of iostreams except (possibly) in the appender and/or viewer. It would also be possible to write a streambuf specifically designed for the log message buffering role, which generated a log_types::string that wasn't a std:string. There might be efficiency advantages in this. It should also be possible to have some sort of shared underlying buffer for a sequence of nested (as a consequence of side effects) log messages so as to do the resequencing requested by Gennadiy.
participants (9)
-
Brian Braatz -
Darryl Green