Hi Louis,

> The original data is binary, all shapes and sizes -- 8 bits, 16 bits,
> 32 bits, signed and unsigned integers, IEEE floating point.  Parsing
> it isn't the problem.

OK, so, you have a clean specification of the structure of the data; that 
always helps :-).

> Generating a program to reproduce the original
> file isn't the problem.

That was what I was getting at.  Again, maybe you've already looked into this 
and the approach your taking as to how that program works is the best that 
can be done.  However, what I was getting at was that perhaps with some more 
knowledge of the problem (ie, the structure of the data that you're trying to 
reconstitute), maybe someone would be able to see an orthogonal approach, 
that wouldn't require such a huge program ... thus eliminating the problem, 
rather than trying to fix it.

For example ... and this really is just an example, to clarify the kind of 
thing I'm talking about ... maybe when you pull the file to pieces, you could 
generate XML.  The reconstitution might then be able to be performed by a 
much smaller program, using the XML as input.

Anyway, just a thought.

I happen to be doing precisely this at the moment (converting a binary file 
into XML and back again).  I prototyped it in Ruby, which took me about an 
hour, then re-wrote it in C++ for speed ... which took me a day!  Of course, 
that's partly because I haven't written a serious piece of C++ in five years, 
but I prefer to think it's because Ruby's just so much better!

Fortunately, the speed-up was larger than the multiplier for Ruby -> C++ 
conversion.  It took me about five times as long to get the C++ going, but I 
got a 20-fold improvement in speed.

Harry O.