Re: [boost] Boost.Logging hex dumps (Was: Boost.Logging: formalreview)

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-11-15 21:29:44

Caleb Epstein <caleb.epstein <at> gmail.com> writes:
> On 11/15/05, Darryl Green <darryl.green <at> unitab.com.au> wrote:
> > Hex data formatting (or any data formatting) shouldn't be part of the
> > library.
> > Or if it should, it probably means the lib shouldn't be dragging in all
> > that
> > std streams stuff that is supposed to be responsible for formatting...
> 
> The proposed Boost.Log library already depends (rightly, IMHO) on iostreams

My point was just that - the hex formatter is surely something that works on 
iostreams, not on "logs". Only if the libary didn't rely on iostreams for 
formatting it would need its own formatting framework. I can see that providing 
some custom formatters that work with streams is tempting but:

> The necessary code to do hex dumps on an iostream should hardly be
> considered bloat. I agree with Gennadiy's assesment that 50 lines of code
> should be more than adequate to do it. These can be in a separate header
> file that is included only by the user. What possible harm could this be?

Scope creep/focus, thats all. I'd really like a solid logging library framework 
with a stable interface - hanging formatting off it is less critical.

I would like to see a bunch of contributed logging lib tools/extensions grow 
(I'll contribute some) - but adding them to Johns todo list won't help get the 
library into a state where it can pass review more quickly (imho).