RE: [boost] Dynamic sized bitset

From: Cliff Green (cliffg_at_[hidden])
Date: 2001-12-12 13:09:55

Hi Jeremy,

Jer> So the idea would be to replace the functions that convert to and from
Jer> std::basic_string with function templates? That sounds reasonable to
me.

Yes - what I had as a template policy was really not the best design, and
template member functions would do much better (or stand-alone template
fcts).

Jer> The most-significant bit first, and the append function would be more
Jer> difficult.

Jer> Both the std::bitset and the dyn_bitset are least significant bit
first,
Jer> which means the appending you want would be prepending to the storage,
Jer> which is not so easy with an array.

I probably should have made a diagram or explained differently ... in any
case whichever bit ordering is used internally is not that important, as
long as the interface is consistent (which you mentioned as well). The
important thing (obviously) is to preserve an ordering when adding or
extracting a value representing more than one bit.

To summarize, what would really make dyn_bitset useful for me (and anyone
with similar needs) is:

1. Single bit appending (e.g. a += operator as mentioned in another
follow-on e-mail), and the container manages the size / number of bits (of
course). This also implies a constructor that allows a zero size on
construction, so that bits can be dynamically added.
2. Extracting / appending groups of bits as integral values.
3. Ability to convert to / from a packed bit buffer ... the underlying need
for this is simply the ability to serialize to an external interface.

Only option 1 really requires member fcts - 2 and 3 could be probably be
written as non-members (I think ... I'll have to give it a little more
thought).

Although not strictly necessary, option 2 seems really convenient and I
think would be used by a wide range of people. 3 is a convenience for those
that need to directly use the bitset in a network, or storage on disk, etc.
It is in effect a serialization mechanism different from the bitset (and
your proposed dyn_bitset) approach, which is to serialize with each bit
corresponding to a character "0" or "1". There are a number of details and
requirements to be ironed out (e.g. zero padding on the trailing char), but
these can be firmed up fairly quickly.

In effect, dyn_bitset with option 1 added would allow pretty much a
replacement of vector<bool>.

Options 2 and 3 provide additional convenience functionality that might be
useful for a number of people. Whether the usefulness is wide enough to
consider adding to the interface of dyn_bitset (either as members or as
non-member utilities) is why I posted (and would still like additional
comments). In any case I'll have options 2 and 3 in my own code, but would
love to use dyn_bitset (if option 1 is implemented), and if I'm doing the
work and enough people find it of use, why not share it? :)

Cliff