Boost logo

Boost :

From: Matt Doyle (mdoyle_at_[hidden])
Date: 2005-11-14 14:16:18


> [mailto:boost-bounces_at_[hidden]]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}


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk