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.