RE: [boost] Dynamic sized bitset

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-04 10:58:50

> From:	Jens Maurer [SMTP:Jens.Maurer_at_[hidden]]
> 
> People here seem to think about a single, unified uni_bitset class
> with a policy template parameter to select between compile-time and
> runtime allocation.  I think this needlessly complicates the issue.

I don't see it as needless or a complication.  See below.

> You can almost never use a class with a policy template parameter
> without looking up the docs first (i.e. policy parameters provide more
> flexibility at a non-negligible cost of ease of use).

That depends upon how it is done, I should think.  If the code looks like
the following, it's hardly a problem:

struct stack_allocation { /* ... */ };
struct heap_allocation { /* ... */ };

template <typename Allocation>
class basic_bitset { /* ... */ };

typedef basic_bitset<stack_allocation> bitset;
typedef basic_bitset<heap_allocation> dyn_bitset;

If the policy is more complicated, or involves more parameterizing types,
then your concern gains credibility.

> Some function that wishes to use a bitset-like object
> in some non-size-modifying fashion needs to be a template anyway,
> either on the policy class (single, unified bitset class) or on
> the whole bitset-like class (two distinct classes: bitset and dyn_bitset).

So there's no difference in complexity.

> In short, I don't see a reason for a unified, single 
> merged class for bitset and dyn_bitset.

Here are a few reasons for a traits class I can think of:

o Maintenance of the code is simpler when there's only one class:
basic_bitset.
o One only needs to learn about one class' interface: basic_bitset.
o One can extend basic_bitset to use a custom allocation scheme.
o There's (purposeful) symmetry between basic_bitset and basic_string that
will reduce the learning curve. (Some will only ever use bitset, some will
only ever use dyn_bitset, and some may customize basic_bitset and use that.
These parallel using string, wstring, and basic_string.)

> Btw, the stack vs. heap allocation choice seems to be mostly a
> quality-of-implementation issue.

I disagree. There are times when your stack space is limited or you have
free store limitations. In those situations, the developer needs to choose
the allocation scheme. Lacking that choice, some developers won't be able to
use the class.

Rob
Susquehanna International Group, LLP
http://www.sig.com