In-Reply-To: <[EMAIL PROTECTED]> On Thu, 12 Dec 2002 19:50:31 -0500 David Abrahams ([EMAIL PROTECTED]) wrote: > This sounds exactly like an argument for uuencoding binary > instead of uuencoding text.
It's an argument for not uuencoding at all. Instead produce safe text directly. > "500" as text is 3 bytes; uuencoded it is 6 bytes. 500 in a > variable-length binary format is 2 bytes; uuencoded it is 4 bytes. Well, "500" probably needs some kind of terminator or length byte. What I had in mind was expressing it base 64, then using a set of 64 safe characters such as 0-9,A-Z,a-z,%@ to encode it. So 500 becomes "7p" if I got the maths right. This is a "safe" string; it doesn't need to be uuencoded. It is 2 bytes rather than 4. > To me, it sounds like you're after persistence, with data structure > evolution between program runs. Serializing/deserializing the data > will probably be an important part of what it takes to get there. OK. My feeling is that it would not be too difficult to make field names and object begin/end blocks available to the archive format, and that this would suffice to support more "serialisation" oriented applications, that I would find useful. > > I don't claim that code like this is the best solution, but in > > practice I have found it works. > > I'd like to see a better one, if it's out there. Do you have something in mind I should be looking at? -- Dave Harris _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
