Re: [boost] Boost.Logging: formal review

From: John Torjo (john.lists_at_[hidden])
Date: 2005-11-14 19:51:09

>>>1. Design: Lightweight interface
>>>Log library brings a lot of dependencies. In some case I do 

>>>I need to use the library in header. IMO log needs to 
>>
>>support/implement some 
>>
>>>lightweight debug abstract interface Something like:
>>>
>>>struct DebugLog {
>>>    virtual void log( string const& ) = 0;
>>>    virtual void log( int ) = 0;
>>>};
>>>
>>>struct Log : DebugLog { ... };
>>>
>>
>>Anybody else wants this?
> 
> 
> Yes, for me that would be useful.
> 

Ok, so I understand you want both the normal interface, and the 
lightweight interface.

> 
>>>3. Design: hexdump
>>>I believe log library needs to provide support for dumping 
>>
>>memory in hex 
>>
>>>format on log file. It could be an addon to core functionality.
>>>
>>
>>I can add this, even though I'm not sure why you'd want this.
> 
> 
> Yes, Yes, I use the log file for an error log. Being able to do a raw (hex) dump of the offending packet would be very useful for postmortem analysis - provided this functionality could still be available in the light-weight version :/ 
> 

Ok, will do.

>>>4. Design: logged assert
>>>I believe log library needs to provide support for custom 
>>
>>assert. Such 
>>
>>>assert would log into log file and invoke system assert 
>>
>>depends in assert 
>>
>>>level. It could be an addon to core functionality.
>>>
>>
>>Well, I want to adapt SMART_ASSERT to allow for this functionality.
> 
> 
> Kind of falls in line with what I said in #3. I want to log the recoverable errors but if it was a non-recoverable error then "log & die" would fit nicely.
> 

Ok, will do.

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!