From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-10 01:47:08
--- "David A. Greene" <greened_at_[hidden]> wrote:
>Javier Estrada wrote:
>> After reading all the email, I'd like to summarize the aspects that need to
>> be balanced in such a proposal:
>> - Instancing
>> a) Static (ala cin, cout, cerr, clog) ?
>> a) Singleton ?
>> b) "Multiton"?
>I'm not sure what you mean here. Are you talking about specifying
Trace stream lifetime and multiple trace stream management is orthgonal issue to the trace stream design. I use trace manager classes for that.
>> - Destination
>> a) Single target
>> b) Multiple Targets - What's better? Composition? using a design pattern,
>> like Decorator?
>Definitely multi-target, IMHO. Maybe I want to print all messages
>to the console (so I can read all of them) but keep a buffer of
>the last N messages so if the program crashes I can see what happened
>leading up to the crash.
It should not be an issue. Each trace stream is a one target. We also should provide some kind of multiplexor facility to support multiple targets.
>> - Optional output information
>> thread id, process name
>Function name, file name, any number of other things. I think much
>of this should be explicitly coded by the programmer (i.e. the actual
>logging function shouldn't add much message text). Formatting should
>be layered on top of logging.
No. a lot of things could be provided automatically, including thread id, line number, file name, time, date, ... Though we will probably need macros support for that(file,line)
>> - Severity (Levels)
>As has been stated a few times (but perhaps not strongly enough), levels
>alone doesn't cut it. IMHO, any good logging library should allow
>controlling of output by specifying module or "mesage type" names (i.e.
>give me the debug output [level 3 and below, or maybe just levels 1
>and 4] for the L1 cache of my processor simulator).
Here what I am using for trace filtering:
a. Template parameter TraceLevelType that encosulate enumaration of possible values, comparizon functions, some other contract functions used by trace stream implementation.
This is regular level: trace entry is active only if trace entry level is more then threshold trace level.
b. Template parameter TraceKeywordType that encosulate real keywods type
Keyword storage, access functions.
This is what other mentioned as ID, page and so on. Used to mark some of the trace entries as belonging to the same area (library, file, class, and so on whatever you prefer)
c. Template parameter TraceCategoryType that encosulate enumaration of possible values, activation and access functions.
This is use to slice trace depends on type of information stored. For example: ARGS, ERROR_TRACE, PROG_FLOW, DATA_FLOW, ...
Here the example of my trace entry:
Trace( PROG_FLOW, "Request Acceptor", DEBUG )
"Got new request of type: " << request_type
>> - Add your own
>Others have mentioned controlling the logger from an external interface.
>I think that's a great idea if it is workable in a generic fashion.
>Perhaps this is something that could be layered on top of the logging
>library as a separate component.
My trace streams provide a way to be configured dynamically by means of specifying configuration string like this:
prefix= time _ : indent;
I did not mention it yet: prefix define format for trace entry prefix; There are 2 additional facilities:
1. Scope Tracing
used like this:
TraceEnterScope( foo );
managed by the trackscope configuration parameter. If scope is tracked trace out put will look like this:
2. assert tracing
If assert if fired it will print backtrace information into the trace stream.
>> IMHO, a logging library for boost should follow the streams philosophy and
>> be based on streams.
>It should also allow other usage if/when appropriate. Could this be
>made a policy somehow?
A free email account your friends will never forget!
Get YOURNAME_at_[hidden] at http://www.emailaccount.com/
Run a small business? Then you need professional email like you_at_[hidden] from Everyone.net http://www.everyone.net?tag
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk