BitArray new design

[Era Scarecrow]

On Thursday, 10 January 2013 at 20:11:38 UTC, Dmitry Olshansky 
wrote:
> You want to mixin a definition of a inner struct BitString into 
> each bit array?

  That was the idea, yes.

> Or include all of functions of BitString to be mixed into 
> BitArray?
>
> If the latter then:

  Well it seems like it should work, that it should include a 
silent pointer to the original BitArray (container) similar like 
delegates do for functions. Odd that it doesn't.  Bug?

  Seems with the problem on that, I'll do a different approach.

  BitArray(StorageType) {
    StorageType memory;

    //now we do memory.length =, and memory.rawBulk[] for direct 
access, may
    //add opIndex removing the need to know rawBulk at all
  }

  StorageType in this case should contain 'rawBulk', and the 
storage type handles the memory allocation, giving access to 
members no different than an array. I have two storage types i've 
written that hopefully handle all cases:

//storage types for BitArrays
struct Dynamic {
   size_t[] rawBulk;
   alias rawBulk this;
}

struct Fixed(int maxBits) {
   size_t[maxBits / (size_t.sizeof * 8)] rawBulk;
   int _length;    //fixed sizes are usually going to be rather 
small

   int length() @property const @safe pure nothrow {
       return _length;
   }
   void length(int setSize) @property const @safe pure nothrow {
       assert(setSize < rawBulk.length);
       _length = setSize;
   }
   void reserve(size_t resSize) {} //fixed
}

  Now when modifying memory referencing just treat memory as an 
array, access the raw data via rawBulk (likely will remove named 
access and go with opIndex). This removes the need for several 
workarounds I have currently. while trying to handle 
compact/allocated memory.