[mailto:boost-bounces@lists.boost.org]On Behalf Of John Torjo Gennadiy Rozental wrote:
BTW before I start, I recalled couple more issues I forgot to mention in original post:
1. Design: Lightweight interface Log library brings a lot of dependencies. In some case I do not want this if
Care to exemplify? What are the dependencies?
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 { ... };
Now I could use DebugLog interface without need to know an implementation. It comes with the price of virtual call. I primarily use this for debug only logging.
Anybody else wants this?
Yes, for me that would be useful.
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 :/
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. Kind regards, Matt Scanned by Fortigate {X3BTB534}