On 01/21/2009 03:52 AM, Henrik Nordstrom wrote:
I am in the same field as Adrian on this. Do not implement consume
operation where data is actually moved.
+1 for Strings.
+0 for I/O Buffers.
When reading from network, part of a memory area is consumed. When it's
full a new area is allocated and the old is forgotten (will get
deallocated when the refcounts held by String:s to that area go away).
Since we have many methods that read from network, and none of that code
is (or should be) capable of allocating new areas when the buffer cannot
be appended to, this is a good example of why a buffer class dedicated
to I/O is needed.
An I/O buffer can add fresh memory area when the old one is close to
being exhausted due to previous I/Os. The class may have methods to
control when the new buffer should be allocated (i.e., define what
"close" means). The vast majority of Strings will not benefit from such
functionality.
consume() of a writeable string is better done as a substr operation,
creating a new String containing the tail, replacing the original. It's
a new offset,length pair within the same memory region.
In D&C design, String::consume() just increases the offset.
In D&C design with a note, String::consume() calls Buffer::consume(),
which just increases the offset.
Alex.
