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

----Original Message---- From: Pavel Antokolsky aka Zigmar [mailto:zigmar@gmail.com] Sent: 15 November 2005 14:55 To: boost@lists.boost.org Subject: Re: [boost] Boost.Logging hex dumps (Was: Boost.Logging: formalreview)
On 11/15/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 11/15/05, Darryl Green <darryl.green@unitab.com.au> 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@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

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).
In my case I follow format presented by some text editors I am used to. It includes both hex and actual data on the right. But I wouldn't insist that much on this particular one. Gennadiy

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).
In my case I follow format presented by some text editors I am used to. It includes both hex and actual data on the right. But I wouldn't insist that much on this particular one. It's ok, but only in some cases. For example, less sophisticated editors go crazy, when trying to display non-ascii characters. And when output contains new line symbols and zeroes the log becomes a mess. I'm not telling that isn't useful (I use it myself from time to time), just telling that IMHO simple solution isn't enouth (for generic
On 11/15/05, Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote: library in boost), but complex is too complex for the logging library. It would be actually nice, if boost did have some kind of pretty formatting library. -- Best regards, Zigmar

"Pavel Antokolsky aka Zigmar" <zigmar@gmail.com> wrote in message news:b9e625b70511151325g7c4820e2l36b7766177b8fac3@mail.gmail.com...
On 11/15/05, Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote:
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).
In my case I follow format presented by some text editors I am used to. It includes both hex and actual data on the right. But I wouldn't insist that much on this particular one. It's ok, but only in some cases. For example, less sophisticated editors go crazy, when trying to display non-ascii characters. And when output contains new line symbols and zeroes the log becomes a mess.
You are not required to use it. You are always at liberty to write your own manipulators.
I'm not telling that isn't useful (I use it myself from time to time),
Just as many other log library users. Gennadiy

----Original Message---- [snip]
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). Many times it useful to see an ascii value of the buffer, right beside
On 11/15/05, Martin Bonner <martin.bonner@pitechnology.com> wrote: the hex numbers (as most hex editors do). For example, a Gennadiy's dumping function (see discussion above) prints it in this way. -- Best regards, Zigmar
participants (3)
-
Gennadiy Rozental
-
Martin Bonner
-
Pavel Antokolsky aka Zigmar