BitArray/BitFields - Review

[Dmitry Olshansky]

On 29-Jul-12 02:08, Era Scarecrow wrote:
> 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.

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
}

}

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.

-- 
Dmitry Olshansky