setting capacity of slices
roger peppe
data to be moved between processing modules:
type BlockReader interface {
ReadBlock() ([]byte, os.Error)
}
type BlockWriter interface {
WriteBlock([]byte) os.Error
}
Writing a block of data hands control of the
data to the receiver; reading a block hands control of it
to the caller (one implementation would be to use a chan []byte).
It would be useful if the controller of a block
could append to a given block that had sufficient capacity without
copying it.
However that's not safe, as we'd like
to allow a writer to carve up a block and send
its component pieces in independent BlockWrites:
e.g.
func Splitter(b BlockWriter, data []byte, size int) {
for len(data) > size {
b.WriteBlock(data[0:size])
data = data[size:]
}
b.WriteBlock(data)
}
There's no way of handing out a slice of data without
implicitly handing out all the rest of data too.
The alternative is that every time a block is extended,
it is copied.
This is always an issue when handing over
control of a slice to somewhere else - the only
way to be sure currently is to copy it, which is often overkill.
How about we allow slicing the capacity of a slice as well
as its length. It could be an optional 3rd expression in a slice
expression x[start:len:capacity], e.g.
b.WriteBlock(data[0:size:size])
I realise that this breaks the current assumption that
&a[cap(a)-1] == &b[cap(b)-1] implies a and b point to the same
slice, but is that actually important?
Rob 'Commander' Pike
-rob
Lorenzo Stoakes
> On 25 February 2011 17:08, Rob 'Commander' Pike <r...@google.com> wrote:
>> I don't think it's worth the added complexity, since you can always copy if you need to, but others may disagree. I suggest filing this as an issue.
>
> easily be mistaken for a[start:step:size], though that's a syntax
> thing.
>
> I agree that it is an issue, however. Is this more of a performance
> issue as copying is an effective work-around?
>
> --
> Lorenzo Stoakes
> http://www.codegrunt.co.uk
>
--
Lorenzo Stoakes
http://www.codegrunt.co.uk