Re: [boost] Re: Re: New Library?

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-01-29 00:19:49

On Fri, 28 Jan 2005 23:02:09 -0500, Preston A. Elder
<prez_at_[hidden]> wrote:
> On Fri, 28 Jan 2005 15:28:31 -0500, John Eddy wrote:
> 
> > Thank you for pointing me to that.  My implementation is quite different
> > but I like many features of the Torjo library.  Some of the major
> > differences between the Torjo library and mine include:
> --- CUT ---
> 
> Something else you might want to consider is different logging mechanisms.
> 
> I have written a logging scheme myself, though it is not char specific (so
> it will support unicode logs), and it is based off boost::format to do the
> log formatting.  The reason for this is that I have applications that need
> to support different languages, and the ordering of variables can be
> different for different languages (think polish or something :P).

The usage of Boost.Format is a nice touch, but I suspect some folks
would prefer just simple strings or an ostream-style interface.

> I implemented a callback mechanism that will be used when a FATAL
> message is received (often people will want to do an exit(-1) or something

This is a nice idea. 

> in there, who knows).  I also added a hex logging facility - to do hex
> dumps for you, which is exceedingly useful.

Yes.   This can be quite handy. 

> Plus I've implemented the logger as an interface, and have written several
> 'back-ends', including:
> "simple": where you specify a std::ostream for log messages to go to, as
> well as being able to specify the log output format.
> "file": where you specify a file (using a file class of my own design) for
> output, where you can not only specify the log output format, but how many
> 'backup' logs to keep (think blah.log, blah.log.0, blah.log.1, etc), how
> big a log can get before it is cycled, and a command that should be
> executed post-cycling (eg. gzip -9).

All 

> "net": where you specify a socket (again, using a class of my own design)
> that all logs will be sent to (ala. netcat), as well as the format of the
> log message.
> "syslog": where you specify the UNIX syslog facility, and it will send
> logs to IT.
> I'm yet to do "eventlog" for the NT event logger, but you get the idea.
> 
> If you're going to submit something to boost (I'm all for it, btw), it
> might be an idea to be able to make the logger extensible in the manner I
> have described above - ie. allowing you to specify different logging
> mechanisms and supporting unicode.
> 
> Though, I DO like the idea of being able to use variable log names.

Meaning the logging level names?

> If you want to look at my logging mechanism, you can see it here:
> http://www.neuromancy.net/viewcvs/Mantra-I/include/mantra/log/?root=mantra
> 
> The interface file specifically is here:
> http://www.neuromancy.net/viewcvs/Mantra-I/include/mantra/log/interface.h?root=mantra&rev=1.8&view=auto
> 

I like a number of the features of this interface, especially the
regex replacement of tokens <date:>, <level:> etc in file_impl.cpp. 
The auto-rotation is also desirable.

Can you comment on the thread safety (or lack thereof) of the Mantra
log class?  E.g. could multiple threads be writing to the same log
simultaneously without messages getting smashed together?

Here are some add-ons to John Torjo's Logging library I wrote that
implement a size-based rotating log like yours as well as a date-based
one.  If you want to archive data on a daily (or other) basis, this
can be useful.  They also allow a callback function to determine the
log name, so users can implement custom filename policies.

http://lists.boost.org/MailArchives/boost/msg74762.php

-- 
Caleb Epstein
caleb dot epstein at gmail dot com