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
