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. HTH Darryl.