BitArray/BitFields - Review

[Era Scarecrow]

On Saturday, 28 July 2012 at 21:49:45 UTC, Dmitry Olshansky wrote:
> On 29-Jul-12 01:39, Era Scarecrow wrote:
>> 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?

  Knowing the size based on if it's compact or the array.length * 
bits would be easy, but to do slices you drop the 
beginning/ending reference pointers, locking it at 32/64bits. If 
you keep that information, why not just include slicing along 
with the rest of it?

>>
>>  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?

  See above.

> works as foreach takes [] when needed automagically :)

  I thought about that after I submitted it, so my mistake on that.

> Just make it a template if it works with any range.
>
> 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.

  True, but you'd still need to specifically convert the array to 
a slice first. So you'd call it func(ba[]), or func(ba.range) or 
func(ba[0 .. $]). Kinda seems silly to require the extra bit 
there.

>>  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.

  See first reply.

> 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.

  Obviously it can't emulate it perfectly, but doing all the basic 
operations should be acceptable. I don't know all of what arrays 
require, but opIndex and length are the largest part to my 
opinion, which I guess is just randomAccessRange (or whatever 
it's called)