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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk