Re: String/Buffer split & encoding

On 01/21/2009 03:41 AM, Henrik Nordstrom wrote:

> The design I'd like to see is
>
> - Low-level refcounted memory area (address, size, refcount).
>
> - Memory area "splitter". (memory area, current used offset). Helper
> class for producing Buffer regions. This is the primary interface for
> producing Buffer regions.
>
> - Buffer, region of a memory area. (memory area, offset, size).
>
> - String, subclass of buffer adding < > == and strstr operators, plus
> case-insensitive variants of == and strstr operators (and maybe < > as
> well). No additional data members.
>
> - A StringV container class allowing large strings to built from a list
> of String:s, supporting vector access (for I/O), incremental strstr
> searches (with a separate state class) and extracting regions as String
> or StringV. Extracting as String may need a copy if the requested area
> is not linear in memory.

I think we should discuss StringV after the dust settles an some code is
committed/used. We should not ask Kinkie to implement it right now.

I do not understand the purpose of "splitter" but since it is a helper
class, perhaps it is not important for this discussion.

I am fine with the rest of the sketch. I think it matches "Divide and
Conquer with a (note)" well. And I agree with the comments you made
regarding refcounting and postponing encodings support work until we
need it.

You do not propose a class dedicated to I/O buffers. I think we would
benefit from having such a class, but we can add it later, possibly as a
part of vectorizing work. Do you want the low-level I/O code to use
Buffer, for now?

Thank you,

Alex.
Received on Wed Jan 21 2009 - 16:37:27 MST