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

From: Andrew Schweitzer (a.schweitzer.grps_at_[hidden])
Date: 2005-11-14 22:16:42

John Torjo wrote:
> Hi Andrew,
> 
[snip]
> 
>>1.1) I haven't had a problem passing loggers around by use using a 
>>logger& or a logger*, but the interface seems to assume that generally 
>>the code will be compiled where the log name is known. Most of the code 
>>I work on is header or dll code that needs to be passed a logger by the 
>>main system.
> 
> 
> Not sure I follow...

I meant there's no technical problem passing loggers around, it just 
seems from the doc it wasn't assumed that would happen... so maybe there 
could end up being problems. None seen so far.

> 
> 
>>1.2.1) I think the static manager makes the design harder to use and 
>>control in a system that isn't a single executeable. This could be 
>>solved by either forcing the user to declare the manager, or possibly by 
>>leaving it static, but making all the functions take an explicit manager 
>>ref or pointer, or making the functions members of the manager.
> 
> 
> If you take a look at log_manager.hpp, you'll see that this is how it 
> happens now. Or have I misunderstood something?
> 

I'll look again.

[snip]
> 
>>1.2.1.1.2) It looks like there could actually be multi-threaded issues 
>>writing to logs from a dll, because, if the log thread is used, both the 
>>dll and the app will start their own trhead to write to the log. 
>>Presumably the log is ultimately a single object, like the screen or a 
>>file. I suppose if the locking uses a "named" lock that the OS api can 
>>look up this could be solved. However, it looks like on windows at least 
>>a Critical Section is used, which I don't think is named, so I don't 
>>think the one or more dlls running the thread and the application would 
>>actually lock each other. It seems like they could step on each other.
> 
> 
> If you specify the appenders/modifiers only in one place (like, in the 
> Executable), there are no problems.

But then the dll can't ask the app for it's logs and attach appenders / 
modifiers too them.

> 
> 
>>1.3) I can't seem to pass around log levels. I think this is because 
>>they are const ints, not members of an enum. This means the following 
>>code won't compile:
>>
>>void SomeClass::Dump(boost::logging::level_type eLevel,
>>		     boost::logging::logger& rLog)
>>{
>>	BOOST_SCOPEDLOGL(rLog, eLevel)
>>			<< "Some Msg" << m_iSomeMemberVariable << endl;
>>}
> 
> 
> At this time, indeed you can't.
> I'll find a solution.
> 
> 
> In particular, log levels can't be members of an enum, since you should 
> be able to add your own at any time.

Maybe just a good old int.

> 
> 
>>2) BOOST_LOG and BOOST_SCOPEDLOG are way too many uppercase characters 
>>to type. :)
> 
> 
> Well, you're right :) But so far can't think of any names that could be 
> shorter...
> 

Yes, maybe we need some parallel processing on that one. Maybe someone 
out there has a good idea.

> 
> Andrew, was this a formal review? I'm asking, since I did not see the 
> "Yes" (accept) or "No" (reject) at the end of it.

Yes.

I have some reservations, described in this e-mail. The most important 
is probably allowing managers to be more easily controlled, and adding 
more doc of the core of the interface. But it seems to work, and the 
perfect can be the enemy of the good. Because my compiler at work is old 
  (no partial specialization, no boost::function) I haven't been able to 
integrate into my large-scale code and test it in a real product. I've 
used it for some projects at home, where it seems to work fine.

> 
> Best,
> John
> 
>