Thanks Axel.
Good to know the first part. I have a couple of comments regarding your
answer to the second part.
In regards to your second question: That would require having an array type
> for every possible size, which isn't really tenable.
>
The idea was to use the same array type (`[(^uint(0)) >> 17]uint64`)
regardless of the actual size. I would use `&s[0]` just like you suggest,
but avoid the use of `unsafe.Pointer`, which would put unnecessary strain
on the GC iirc, because the memory pointed to would be scanned
conservatively (basically assuming everything in there could be a pointer).
However, I realize now that I over-complicated the type def. I guess I
should just store a pointer to the first element lik you suggest, but not
as an unsafe.Pointer:
type BitSlice {
data *uint64
len int
cap int
}
That surely doesn't break any rules as a data type, and I guess there is no
chance the GC will start playing games with the underlying array any time
soon.
> It does also mean, however, that you have to very carefully and tediously
> re-implement a bunch of language primitives using unsafe
This is actually relatively straightforward and mostly unavoidable, since I
already need to do those checks to properly panic when someone tries to
access bits padding bits if the BitSlice has a non-multiple of 64 length.
It'll boil down to something like `if uint(i) >= uint(b.len) { panic(...)
}` in most cases, which isn't all that bad.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
