What have I missed?

[Era Scarecrow via Digitalmars-d]

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