Boost logo

Boost :

From: Dave Harris (brangdon_at_[hidden])
Date: 2002-12-13 10:06:37

In-Reply-To: <uwumewxm0.fsf_at_[hidden]>
On Thu, 12 Dec 2002 19:50:31 -0500 David Abrahams
(dave_at_[hidden]) 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

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


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at