RE: [boost] Proposal: Logging library

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-08 22:45:20

Hi,

I have "Trace streams" library that works for me for some time now and I was going to share it also. I do not have time at the moment to boostify it but I would gladly participate in logging library disscussion and development. Below couple notes. Main idea is that logging library should be more flexible.

--- "Terence Wilson" <tez_at_[hidden]> wrote:
>I second that emotion. In fact, I just spent 3 weeks putting together
>something with everything you ask for except thread awareness. Logging
>classes seem to be a candidate for the most reinvented wheel- they seem
>to pop up every six months or so in the magazines.
>
>> -----Original Message-----
>> From: boost-admin_at_[hidden] 
>> [mailto:boost-admin_at_[hidden]] On Behalf Of Ernie Makris
>> Sent: Monday, April 08, 2002 6:48 PM
>> To: boost_at_[hidden]
>> Subject: [boost] Proposal: Logging library
>> 
>> 
>> Hello Fellow Boosters,
>> 
>> I'd like to propose the design and development of a logging 
>> library to be included in boost.
>> 
>> I've been thinking about what boost lacks, and this is one 
>> area of utility that I think would benefit the boost community.
>> 
>> There are a great many examples of logging examples. Some 
>> designs I have been thinking about are:
>> - based on iostreams 

This is very limited. I should be able easiily switch (staticaly or dynamically) file tracing, shared memory tracing, socets tracing, CORBA tracing and so on. Another issue is coexistance of several trace streams in the same program (for example, one is debug log and another is session log used for rollbacks) and sharing same trace statements amoung them.

>> coupled with the work being done with the format 
>> library
>>   by Samuel Krempp.
>>   It would look like the following:
>>   log << log_debug << log_format("%e %1") % "config file not found";
I used to prefer ostreams style. But it should not matter. Anything should work.

>> 
>>   where there would be a log formatter that would have extra format 
>> specifiers.
>>   For example, the %e above could print the errno for a failed file 
>> operation.

I mean that tracing stream should know about errno?

>> 
>>   The log stream would support levels, and a default level. etc... 

only level is not enough.

>> Everything
>>   you would expect from a capable logger.
>> 
>> - Something similar to log4j. There is already a log4cpp, 
>> which is a port
>>   of log4j to C++.
>> 
>> Some basic requirements:
>> - Some basic sink types (file, console, ring buffer...)
>> - Ability to log based on levels
>> - Ability to turn logging on/off dynamically

and at compile time but without macroces.

>> - Focus should be on good performance, and usability of the 
>> API. Make it
>>   easy to setup and use logs.
>> - Useful, built in format specifiers.
>> - As fast a possible.

It was extreamly important for me that tracing was almost opaque in realease mode.

>> - Parameterizeable thread safety. Don't penalize programs 
>> that do not need 
>> thread
>>   safe logs.

Thread-safety is orthogonal issue and users in singe-threaded applications should not bother at all.

>> 
>> Is there any interest in such a library.
>> 
>> Thanks
>> Ernie

Regards,

Gennadiy.

_____________________________________________________________
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