On Fri, Aug 08, 2014 at 11:30:07PM +0000, Era Scarecrow via Digitalmars-d wrote: [...] > 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? [...]
I think this indicates that perhaps there is not a single BitArray type that will satisfy everybody, but perhaps 2-3 related types that share some algorithms. At least the following types come to mind (these are all temporary names so please don't bust out the rainbow bikeshed just yet): - SmallBitArray: fits inside a ulong, and has value semantics. Behaves like a ulong: minimal cost for passing it around, making multiple copies of it, etc.. Basically for juggling bits in a ulong. - StaticBitArray: a value type that fits inside n ulong's. Appends only work up to the max capacity of n ulong's. This one is mainly for people who need to manipulate bitmasks, perform bit operations en masse, etc.. Backed by an embedded static array, so it has value semantics, and you can pass it around, copy it, etc., without worrying about aliasing. - DynamicBitArray: a reference type backed by the GC. This one is for people who are after something that behaves like D dynamic arrays; slicing is supported (by means of extra info about how many bits at the beginning/end of the array is actually part of an array, so you can slice it at arbitrary bit positions not aligned with word boundaries), as is arbitrary appending, etc.. The emphasis for this one is memory efficiency (e.g. for people who need to store massive numbers of bools without wasting an entire byte per bool), at the cost of potentially slower copying / overhead of maintaining start/end bit indices, etc.. Obviously, these types are closely related, so they will probably share quite a good number of common algorithms. So potentially they can be implemented as a core of common functions that can work on all 3 BitArray types, with a few customized methods for each type. T -- I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright