On 29-Jul-12 13:18, Era Scarecrow wrote:
On Sunday, 29 July 2012 at 09:03:08 UTC, Dmitry Olshansky wrote:
On 29-Jul-12 12:55, Era Scarecrow wrote:
Doing it this way the arguments being passed as reference slices
would ensure unneeded copies wouldn't be made. On the other hand a
smaller portion of the code would need to be updated. Along with that
a slice could be set as COW allowing quite a bit of flexibility.
Thoughts?
Hm... and small array optimizations go where? BitArraySlice won't be a
full reference type if it does it.
I was thinking about that; If need be the slice can point to another
slice which holds the actual small array (Kinda a long workaround). The
way to small array optimization to work would be if BitArray generated
it, since when you go to slicing you either reference the original data
in the slice, or you could drop the small array optimization; although a
loss it would simplify code until you come back to it once the code is
working the way it should.
Another idea is to convert the struct into a class instead, which
would allow some options, but won't be a perfect fit, and inheritance
could be used; which would solve some of the small array optimization,
but at what cost?
I have simpler suggestion. Maybe doing it as 2 containers:
BitSet is a plain value type with small array optimization (what you
called BitArray in last 2 posts) and no slicing (only as opSlice() i.e.
as a whole). Best used for small things under < 1000 bits (as even dup
will be cheap enough).
BitArray is class or struct that has reference smenatics and drops small
array optimization in favor of having simple & fast slicing
Best used for big arrays with no less then 100-200 bits.
--
Dmitry Olshansky
