BitArray/BitFields - Review

[Era Scarecrow]

On Saturday, 28 July 2012 at 22:19:05 UTC, Dmitry Olshansky wrote:
> Mhm? Not getting you it at all. What's locking it ?
>
> What's wrong with:
> struct BitArray
> {
>
> union {
> 	struct {
> 		size_t[] data;
> 		ulong length;	//in bits
>
> //length in words would be just
> // (length + size_t.sizeof*4) / // (size_t.sizeof*8);
> // as it's a power of 2 it should get optimized
>
> 	}
> 	size_t[2+ulong.sizeof/size_t.sizeof] compact;
>
> // and say 1 bit is used for isCompact would be great if it 
> could use // the least significant bit of pointer from data[], 
> dunno if it's easy enough

  I'd rather not rely on the pointer at all as a reference for if 
it's compact. If the array is changed later to a template that 
could accept bytes, then where does that leave you? When the 
slice doesn't need to know more of the beginning, it can re-slice 
it to a lesser more appropriate size. It may very well soon 
contain a third entry in the union for main operations and use 
the larger size_t just for canUseBulk (Actually that sounds 
better to me).

  Besides, separating the slice suggests 'length' is not part of 
the union struct. Sure it's convertible to [0 .. length], but 
it's no longer convertible back to BitArray (Unless you make a 
whole new array and conversion/copying which takes a lot of 
time). If you do that, why not do BitSlice from the beginning 
which holds BitArray, but then if you do that why make them 
separate at all? It doesn't make sense to me. I can see making a 
separate range for the front/popFront/empty if you really wanted 
to use those, but it wouldn't change how it would work.

> then Range would be:
>
> struct Range{
> 	BitArray* array;
> 	ulong start, end;
> }
>
> to mark [start..end] piece of it?
>
>> If you keep that information, why not just include slicing 
>> along with the rest of it?
>
> I'm not seeing slicing easily integrated just because length is 
> known.

  Beginning and ending are known, so slicing can be added at no 
extra cost.