Boost logo

Boost :

From: Pavel Antokolsky aka Zigmar (zigmar_at_[hidden])
Date: 2005-11-15 09:54:38

On 11/15/05, Caleb Epstein <caleb.epstein_at_[hidden]> wrote:
> On 11/15/05, Darryl Green <darryl.green_at_[hidden]> wrote:
> >
> > > >>>> Ok, will do.
> > > >>>
> > > >>> But note that will can bloat the library. Showing hex data is a much
> > > >>> harder
> >
> > 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
> for message formatting and buffering of partially-formatted messages. I
> can't see why or how this dependency could be reasonably eliminated without
> major sacrifices to the usefulness of the library.
> 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?

It would not hard of course, but I think this code does not belong to
the logging library. The simplest solution can be easily done by user
(i.e. std::string hexDumb(const char* buff, size_t len)) but a
flexible solution, as would be expected from boos library is much more
complex. For example, in some cases I do not want to print non-ascii
characters in hex dump, in others I do. The grouping depends on length
of the data worlds I'm working with, and also should be configured,
and so on.
My point is that the simple solution is not even worth implementing,
and general solution is definitely out of scope of logging library.

Best regards,

Boost list run by bdawes at, gregod at, cpdaniel at, john at