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.
Received on Wed Jan 21 2009 - 16:51:08 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 21 2009 - 12:00:26 MST