Boost logo

Boost :

Subject: Re: [boost] [B-tree] Continuing development
From: Brian Wood (woodbrian77_at_[hidden])
Date: 2010-09-27 19:00:00

<woodbrian77_at_[hidden]> wrote:
>> Just fyi, I've been experimenting with a similar string --
>> .
>> If an operation would result in a string with length more than 255,
>> an exception is thrown. ?This allows the length of the string to be
>> marshalled with one byte. ?As you mention this limitation is not a
>> problem in many circumstances. ?I'd quibble a little with it not being
>> suitable for demanding applications. ?I think it is fine to use it in that
>> context, but that you might need to also use other string classes.
> Why not use a compressed uint type? Google's Protocol Buffers
> compressed uint compresses an uint just fine, below 128 will be
>represented in one byte, etc..., it works very simply, by just having
> the MSB be a marker indicating the last byte of the integer if it is
> zero, thus it is base 128 instead of base 256 per byte, so as an
> example:
> hex -> compressed bits
> 0 -> 0000 0000
> 1 -> 0000 0001
> 300 -> 1010 1100 0000 0010
> And so forth, and if you have looked in the protocol buffer source it
> decodes each byte very quickly and efficiently. So if you are worried
> about space, you could use this (especially since I have many use
> cases where strings would exceed 255 characters, and we need a
> 'bytestream' type or so too).

I've thought about doing that and I'm using that technique in one
place in my library. The only thing I can say is I like the documentation
effect that the name lil_string has. I don't claim what you suggest is a
bad idea, but at the moment I'm happy with what I have.

Brian Wood
Ebenezer Enterprises
(651) 251-9384

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