|
Boost : |
From: Hoeffner, Detlef (Detlef.Hoeffner_at_[hidden])
Date: 2002-04-11 03:48:40
> 1. The bottom layer contains the sinks (a base-class for
> user-defined sinks, and pre-implemented memory, file, tcp/ip
> and a platform-dependent interactive display).
I like the idea to support all these different sinks.
I would appreciate to use a very general design that is usable
for logging as well as for other purposes. In detail I suggest
to provide a std::streambuf - factory that creates streambuf's
from URL-like strings.
This would be a highly reusable factory to use io in a very
device independent manner.
Regards
Detlef
-----Original Message-----
From: Andras Erdei [mailto:ccg_at_[hidden]]
Sent: Donnerstag, 11. April 2002 09:37
To: boost_at_[hidden]
Subject: Re: [boost] Logging library - Organization of effort
On Wed, 10 Apr 2002 09:59:38 -0400, "Ernie Makris"
<ernie_makris_at_[hidden]> wrote:
>The question now is, how to proceed.
>I think that people that said: "I have logging library X" should place the
>code of the said library on the boost server. I've created a directory
named
>\logging-library.
What's the deadline ? (I'm in the middle of writing one...)
If anyone want to comment (so i can incorporate ideas during
the developemnt) my current design consists of three layers.
1. The bottom layer contains the sinks (a base-class for
user-defined sinks, and pre-implemented memory, file, tcp/ip
and a platform-dependent interactive display).
The first three sinks have no locking mechanism
(i assume that each thread will use a separate
logfile etc), but the last one exists in both
thread-safe and thread-unsafe forms.
2. The middle layer is essentially:
#define LOG diagnostic() << hack( __FILE__ , __LINE__ )
diagnostic() returns a (thread-specific) string stream;
hack()s dtor automagically appends the source file name,
line # and timestamp information, then sends the content
of the stream to the sinks active for the curent thread.
It can be used as:
LOG << "this is logged " ;
Additionally, there is an object whose ctor/dtor calls
the indent()/undent() members of the sinks, passing in
__func__, __FILE__, __LINE__ -- my sink implementations
indent with spaces for file logging, and create/close
sub-branches in a tree-view for interactive logging.
I don't know how customizable this should be (someone
mentioned using < and > instead of indentation).
The sink-management will also be part of this layer; to
prevent coupling with the thread library threads can only
manage their own sinks -- what i don't know is how to
remove sinks... Maybe there'll be only a function for
detaching all the sinks.
3. The topmost layer is a bunch of macros for level-based
logging.
Message filtering occurs at the topmost layer (levels
can be turned on/off at compile time), and in the sinks.
(There is no filtering for file, tcp/ip & memory sinks,
and the interactive sink will have a pattern-based filtering
mechanism; the filters are set runtime, by the user.)
Any comments/suggestions ?
TIA
andras
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk