BitArray/BitFields - Review

[Dmitry Olshansky]

On 29-Jul-12 01:39, Era Scarecrow wrote:
> On Saturday, 28 July 2012 at 21:30:21 UTC, Jonathan M Davis wrote:
>
>> Well, it seems that my comment was somewhat misplaced in that BitArray
>> isn't a range but a container. My comment was directed at opSlice on
>> ranges. Container types should return whatever range type is
>> appropriate. That will usually be a struct of some variety. I'd have
>> to study BitArray and your changes to determine what the appropriate
>> type was here, but it sounds like you were talking about duping the
>> contents with opSlice, which would be highly irregular. Normally,
>> ranges over containers are light wrappers which can iterate through
>> and potentially alter the elements in the container, and duping up an
>> array as the range type doesn't work like that. But depending on what
>> BitArray is doing exactly, it might be appropriate. I don't know.
>
>   An array suggests you can control the size of the array, however if
> you are forced to work in 32increments (or more if 64bit), that makes it
> highly hard to control without making it a slice to begin with. Consider
> without slices (range control)

A strange jump to conclusions? Why can't array know it's size in bits 
and capacity in words?

>
>   BitArray ba; //size 32/64bit
>
>   ba.length = 42; //life, the universe and everything
>   assert(ba.length == 42); //fails, can't set length except by
> increments of 32/64
>
>   ba ~= true; //what's the size now? Or are all appending operators
> invalid unless it's a slice?

43 ? Why should it use 32/64 bit increments?

>
>   foreach(b; ba) {
>     //fails, can't go over range.
>   }

works as foreach takes [] when needed automagically :)
>
>   auto slice = ba[]; //converts to BitSlice
>
>   foreach(b; slice) {
>      //works
>   }
>
>   BitSlice func(BitArray ba);
>   BitSlice func(BitSlice ba); //two versions of function needed? If
> convertable between the two, then you only lose the begining/ending
> length offsets.
>

Just make it a template if it works with any range.

>   T func(T)(T ba) if (is(T : BitArray)) // correct? Potential loss of
> information.
T func(R)(R ba)
  if(isRandomAccessRange!R && is(Unqual!(ElementType!R) == bool))

Would be far more general. As a bonus it will work with built-in arrays 
of bool or anything compatible.

>
>   BitSlice x = ba[1 .. 10];
>   BitArray y = func(x); //range lost, beginning/ending at max regardless
> of size
>

Certain functions would need to take a BitArray if they need to change 
it size, append, prepand etc.

>   Honestly that doesn't add up to what I call an 'array'. It should look
> like an array, act like an array, and besides not being able to specify
> the array as separate from the entire BitArray (Ie const(int)) it's
> otherwise should not be distinguishable from an array.

It's damn hard to emulate built-in array. And I'd rather not to see this 
emulation half-working.

And in say C++, std::vector (and most arrays in other languages I know 
about) is not sliceble at all or slices are different type, or they do 
copy the whole thing. So I'm not sure what kind of array you are used 
to.  D's built-in arrays are rare beasts with their own issues, even 
with the fair deal of built-in language/runtime support they have.

-- 
Dmitry Olshansky