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

From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2005-11-15 10:44:05

----Original Message----
From: Pavel Antokolsky aka Zigmar [mailto:zigmar_at_[hidden]]
Sent: 15 November 2005 14:55
To: boost_at_[hidden]
Subject: Re: [boost] Boost.Logging hex dumps (Was: Boost.Logging:
formalreview) 

> 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.
It's such a common requirement that I think it does.

> For example, in some cases I do not want to print non-ascii
> characters in hex dump, in others I do. 
? How does a hex dump contain anything other than hex digits and space (to
separate bytes).
You might want a way of controlling whether to use upper or lower case
letters (but I wouldn't bother).

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

-- 
Martin Bonner
Martin.Bonner_at_[hidden]
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ,
ENGLAND Tel: [phone]