Re: [boost] [Review] The review of the Boost.Logging library starts today, November 7th

From: John Torjo (john.lists_at_[hidden])
Date: 2005-11-13 15:33:53

Eelis van der Weegen wrote:
> I have a couple of design questions:
> 
> 
> 1. What is the fundamental reason that logs cannot be declared/defined with 
> something as simple as  boost::logging::log mylog ("mylog");  ? What 
> special needs do you have that rule out this approach? (I took a brief look 
> at the source code, got a vague idea what you were trying to accomplish, 
> and have some ideas about how the same may be accomplished without 
> resorting to macro's, but would like to hear your explanation and reasoning 
> first.)

Note: you can actually do the above: it's called "Scoped Logs" - look it 
up in the docs:

logger gui("app.gui");
BOOST_SCOPEDLOG(gui) << "something GUIsh" << std::endl;

> 
> 
> 2. I am very skeptical about logs having both a C++ identifier and a string 
> name. The documentation argues that the string names bring "extreme 
> flexibility" in the following two ways:
> 
> a: External identification
> 
> While I agree that external identification may sometimes be useful to some 
> users, is it really necessary to integrate it into the library? Would the 
> users who require such functionality not be able to simply use something 
> like a   std::map<std::string, log *>  ?
> 

In the simplest of cases (forgetting the thread-safety issues), perhaps 
that would be enough. In this case, you would then have to provide 
methods to add/del appenders/modifiers, and add/del them for each log -- 
which I consider troublesome.

See Log Hierarchies below

> b: Log hierarchies
> 
> I do not question the usefulness of log hierarchies, but am not convinced 
> that string names (and wildcard queries) are the best way to implement them.
> 
> It seems to me that all that is needed to be able to form hierarchies of 
> logs, is a way to express parent->child relationships between two logs. 
> Indeed, something as simple as  parent_log.append_child(child_log);  should 
> suffice.
> 
> Wildcarded queries would simply become logs (or some sort of log-proxies) 
> by themselves, that the user must manually connect to the desired sink logs.
> 
> While this approach is slightly more cumbersome, I feel that getting rid of 
> all the string name cruft is definitely a big win.

I feel that using strings for log hierarchies provides for very loose 
coupling. More to the point, you can have multiple modules (or DLLs, for 
that matter) that need to do logging. You can externally identify such a 
log by a string, and somewhere else, specify its appenders/modifiers.

Therefore, even if you have multiple DLLs, each of which does logging, 
you can manipulate their appenders/modifiers in the main application module.

Say I want to create this log: "charts.gui".

If you were to use your approach, lets say you would first get to the 
root log, like this:

get_root_log().

But how do I get to the charts log? More or less, I'd end up using some 
string again:
get_root_log()->child("charts");

Or, how would you go about enumerating your logs? Once you get to a 
reference to a log, what can you do with it? It would be just a mere 
pointer...

Also, I believe that if you're not using strings, in time you can lose 
the big picture: hey, X is a child of Y, which is a child of Z, or it is 
T, or W?

Finally, in a large application, you could end up with different modules 
that have, lets say, a special 'gui' log. If so, you can give each such 
log the "gui" suffix. This way, you can manipulate all gui logs like this:
"*.gui.*"

For instance, to write all the GUIsh information to the debug window, 
you'd say:
manipulate_logs("*.gui.*").add_appender(write_to_dbg_wnd);

Best,
John

-- 
John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit!
-- http://www.torjo.com/cb/ - Click, Build, Run!