I'm not sure I fully understand, but it sounds like you have a parser for this binary format, and you control the code for it. So this answer is built on that assumption.
A parser will in some way be filling up structs, classes, or whatever data structure your language has. If you implement a ToString
for everything that gets parsed, then you end up with a very easy to use and easily maintained method of displaying that binary data in a human readable format.
You would essentially have:
byte[] arrayOfBytes; // initialized somehow
Object obj = Parser.parse(arrayOfBytes);
Logger.log(obj.ToString());
And that's it, from the standpoint of using it. Of course this requires you implement/override the ToString
function for yourObject
class/struct/whatever, and you would also have to do so for any nested classes/structs/whatevers.
You can additionally use a conditional statement to prevent the ToString
function from being called in release code so that you don't waste time on something that won't be logged outside of debug mode.
Your ToString
might look like this:
return String.Format("%d,%d,%d,%d", int32var, int16var, int8var, int32var2);
// OR
return String.Format("%s:%d,%s:%d,%s:%d,%s:%d", varName1, int32var, varName2, int16var, varName3, int8var, varName4, int32var2);
Your original question makes it sound like you've somewhat attempted to do this, and that you think this method is burdensome, but you have also at some point implemented parsing a binary format and created variables to store that data. So all you have to do is print those existing variables at the appropriate level of abstraction (the class/struct the variable is in).
This is something you should only have to do once, and you can do it while building the parser. And it will only change when the binary format changes (which will already prompt a change to your parser anyways).
In a similar vein: some languages have robust features for turning classes into XML or JSON. C# is particularly good at this. You don't have to give up your binary format, you just do the XML or JSON in a debug logging statement and leave your release code alone.
I'd personally recommend not going the hex dump route, because it's prone to errors (did you start on the right byte, are you sure when you're reading left to right that you're "seeing" the correct endianness, etc).
Example: Say your ToStrings
spit out variables a,b,c,d,e,f,g,h
. You run your program and notice a bug with g
, but the problem really started with c
(but you're debugging, so you haven't figured that out yet). If you know the input values (and you should) you'll instantly see that c
is where problems start.
Compared to a hex dump that just tells you 338E 8455 0000 FF76 0000 E444 ....
; if your fields are varying size, where does c
begin and what's the value - a hex editor will tell you but my point is this is error prone and time consuming. Not only that, but you can't easily/quickly automate a test via a hex viewer. Printing out a string after parsing the data will tell you exactly what your program is 'thinking', and will be one step along the path of automated testing.