[boost] Re: logging lib, v1.3

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-11-01 03:21:07

"Darryl Green" <darryl.green_at_[hidden]> wrote in message news:loom.20041031T021329-215_at_post.gmane.org...
> Johan Nilsson <johan.nilsson <at> esrange.ssc.se> writes:
> > "Darryl Green" <darryl.green <at> unitab.com.au> wrote in message 
> news:loom.20041030T055250-159 <at> post.gmane.org...
> > > The library actually supports overriding the types used for logging 
> including
> > > the threading primitives used, which (unless you use the ts_appender) is 
> only
> > > a simple mutex and corresponding scoped lock class. So you should be able to
> > > keep those managers happy by using/wrapping other mutex/lock classes.
> > 
> > I don't recognize that, is it documented somewhere?
> 
> No, but it will be. The lib is a bit pre-release at present. Maybe 0.3 would be 
> a better rev number than 1.3...
> > 
> > > 3) Something quite radically different such as a log where the "stream" is
> > > something into which structured log information can be assembled, and
> > > the "string" carries that information to appenders that use that structured
> > > information (format it for textual output, write it to a database table...).
> > 
> > Is this actually possible? How?
> 
> Have a look at log_fwd.hpp You will see that there is a default_log_manger 
> struct which defines the char_t, string, stream types.
> 
> You will also see that log_manager is a (trivial) metafunction class taking an 
> int parameter that returns the default_log_manager type by default. In log,hpp 
> log_manager<0>::type is used to obtain the types used throughout the logger.
> 
> You can write a specialisation of log_manager<0> and include this before 
> log.hpp to replace these types.
> 
> The "stream" type needs to have a str() member function to convet it to 
> the "string" type. In an (unreleased) version this was avoided by having a 
> separate to_string function as part of the manager policy - it might end up 
> that way again?
> 
> Of course at most of the supplied appender and modifier functions will not work 
> with a wildly different "string" type, although the simple write_to_file 
> function should work with anything with a reasonable operator<< defined.

Having the interface string-based makes things easy in the general case; such as when adding modifiers (prependers? Sorry, I'm in no way friendly with the naming of the concepts yet). However it makes things extremely difficult for integration with structured log facilities. I'd really, really not like to use iostreams, sscanf or regex to extract information out of the string at the back-end, converting into correct data types etc ... ;-)

I do kind of like the current implementation's interface, but I'd prefer a structured internal format with possibilities to a stream-based interface. But again, that's just my 0.02EUR.

BTW, is a single ts_appender instance meant to be used by multiple threads? In that case the code inside ts_appender::operator() is not thread-safe ... wait a minute .. just saw that there was another lock inside ts_appender::create_thread(). Still feels like checking the same thing twice (at least).

Regards // Johan