New logging design (was Re: [Box Backup-dev] COMMIT r285 - box/chris)

[Martin Ebourne]

On Thu, 2005-12-29 at 12:45 +0000, Chris Wilson wrote:
> I'm planning to implement:
> 
> A BOX_LOG(level, stuff) macro similar to the one you proposed, using
> iostreams.
> 
> Macros BOX_TRACE, BOX_DEBUG, BOX_INFO, BOX_WARNING, BOX_ERROR, BOX_FATAL
> which supply the LEVEL argument to BOX_LOG. BOX_TRACE is completely
> compiled out of non-debug builds.

I'm not sure why both TRACE and DEBUG are needed, nor why you'd use one
over the other. Have you plans for using these for specific things?

> An abstract Logger class with two methods, Log(level, std::string), and
> Filter(level). Implementations for Console and Syslog.

Ok. I take it Filter() sets the minimum level that will be logged? Since
this is on each Logger class I presume it will be possible to set the
level differently for each output method?

> A hidden static std::vector<Logger> of enabled loggers, which can be
> added and removed with static methods like Log::Syslog(bool),
> Log::Console(bool), and also Log::Add(Logger&) and Log::Remove(Logger&)
> for custom loggers.

I take it that the Log class will also have a static Log method that
calls the Log methods on the underlying Logger objects?

> A hidden static boolean to disable all logging temporarily, and a class
> which you can create on the stack to disable logging and have it
> re-enabled automatically when the class is destroyed.

Is this needed for a specific purpose?

> A critical section on Win32 to prevent the vector of loggers from being
> concurrently modified and used.
> 
> Do you need more detail?

No, that's the level I was interested in. Looks good.

Another question - I notice you branched for this off trunk again. But
you've also got another branch for the visual c stuff. What state is
that in - is it ready to be merged yet? Thinking you're just going to
end up creating yourself conflicts given the intrusiveness of the logger
change.

Cheers,

Martin.