On Friday, 8 August 2014 at 22:43:38 UTC, Andrei Alexandrescu
wrote:
A thought: if whatever work on bit arrays you do isn't fast,
it's probably not worth doing; people who opt for that kind of
packing are most often performance motivated.
Alignment is often not an issue - you handle the setup/teardown
misalignments separately and to the bulk 64 bits at a time.
Instead of a full-blown abstraction you may want to instead opt
for defining some simple primitives using ulong[] that are
accessible to people having data embedded in odd places. The
bit operations in std.allocator would be good and practical.
And now i'm confused. There's enhancement requests for making it
so you can prepend or append to the bitarray really quick, which
ensures it's not aligned right unless you rebuild the entire
thing. Quite often you'll be working with only a few bits at a
time vs large bulk operations, and if they don't align right
somehow, then either bit-shifting has to be present and sort of a
leap-frog approach, or they align at the same place so you can
treat it more like an array...
Of course you can always expand it so 1 bit becomes 1 byte, and
then afterwards repack it into something smaller for storage
purposes...
On Friday, 8 August 2014 at 22:46:44 UTC, safety0ff wrote:
Yea, one of those was my code and the other was somebody else's
PR that I revived since they weren't responding.
I was moving forward with the philosophy that we should make
the existing implementation as correct as possible and leave
new features to new designs.
Not surprising. We want to move forward/advance as much as
possible. Kinda my internal motto when playing chess :P
I think it will be difficult to make a "one size fits all"
BitArray that satisfies everybody's wishes.
E.g.:
Bit level slice operations versus performance. Value semantics
versus D slice semantics. Having compatibility with other parts
of phobos versus having a maximum of 2^35-1 bits on a 32 bit
system.
This is not as bad making a one size fits all fixed point
integer, but it's not pleasant either.
I recall trying to satisfy everyone's requests. The only thing
that really came up was it was sometimes a reference (>64 bits)
and sometimes a value type (<=64 bits) and that was confusing
only because it wasn't consistent. That and someone wants to be
able to have a static size that probably doesn't rely on
allocation at all. Possible but not sure how to make it...
As someone mentioned before, i think it comes down that we
really aren't sure what it is really for, it hasn't been fully
defined. Is it a storage container? An array? Is it mostly so we
can foreach over the elements for something? Is it for bit
packing/unpacking for compression? (Which is how i see it
mostly). Encryption?
Suddenly the idea of having it attached to a portion of memory,
then that's converted to a byte array that can be treated as a
normal array works fine, then just having it update the original
array on a sync call or something comes to mind... That might
work... But who owns the data? If the GC owns it, then you create
a portion of memory and assign it, or you tell the BitArray this
memory goes to this slice of the data, and 'do this' with it.
Hmmm new ideas... but doesn't seem easy to do...
