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).