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.
