Rene Rivera <grafik.list <at> redshift-software.com> writes:
John's code is very close to that. If the code that his BOOST_LOG produces could be reduced to a simpler public interface so that those of us who don't want to use the macros can use instead, it would make it a winner for me.
Hi Rene I've been writing/using a lib that librally borrows some of the techniques John was using, but I've separated the log object from the "manager" that handles the connection tables to suit my requirements better and hopefully to make it easier to plug in alternative approaches. I've kept the macro because the macro has the advantage of not even evaluating arguments to the expression/function call when a log is turned off. If you are prepared to forgo that, I think you can just repackage the interface. #define LOG(THE_LOG) \ if (logging::msg<logging::detail::manager> m = THE_LOG); else m.get_stream() becomes (for a printf interface): log_printf(logger &l, const char *fmt, ...) { logging::msg<logging::detail::manager> m = l; if (!m) { char buf[101]; va_list args; va_start(args, fmt); int n = vsnprintf (buf, 101, fmt, args)); va_end(args); if (n < 0) return; m.get_stream().write(buf, n > 100 ? 100 : n); } ) I guess for your static logs this would be wrapped up in a class template with a static logger instance and trace function, but that should be all it takes to limit the scope of changes?
One important aspect of having a public macro-less interface, is that it would allow those with current log facilities (like me) to recode without changing all the logging calls. Which is a rather large task when you have a few million lines of code in your application :-\
Fair enough! How many logs and how many sinks/appenders do you have/need for this application? Regards Darryl Green.