Re: pseudo-specs for a String class

> On Mon, 2008-08-25 at 22:01 +0200, Kinkie wrote:
>> On Mon, Aug 25, 2008 at 8:03 PM, Alex Rousskov
>> <rousskov_at_measurement-factory.com> wrote:
>> >
>> >> (04:59:40 AM) ***kinkie is starting to write pseudo-specs for a
>> String
>> >> class..
>> >> (04:59:52 AM) kinkie: along the lines of what we talked about.
>> >
>> > Hi Kinkie,
>> >
>> > I noticed on the IRC that you are starting to work on the String
>> > class specs. This would be very useful, especially if it solves a few
>> > general buffering problems along the way.
>> >
>> > I have not seen the discussion you refer to yet (I have not fully
>> caught
>> > up with older squid-dev posts but I do not see any with String in the
>> > subject) but please coordinate your work with
>> > http://wiki.squid-cache.org/Features/BetterStringBuffer which has
>> quite
>> > a few ideas and comments.
>> >
>> > If your plans differ from what is being discussed on that Feature
>> page,
>> > let's try to unify them before you get too far. In fact, since the
>> > discussion on that page has not resolved all the issues, some
>> > unification would be required in either case.
>>
>>
>> They not differ significantly, and I'm currently coding an out-of-tree
>> merge-friendly prototype.
>
> Ah. I thought you are writing specs, not coding, sorry.
>
>> The basic idea is somewhat similar to JIT strings:
>> two classes work in tandem: String and String::Buf.
>> String is the public interface, String::Buf (which is private)
>> performs memory management.
>
> Yes, I think this is similar to portions of the BetterStringBuffer page.
> I will try to mark questions below that are related to
> unresolved/conflicting issues on that page with (QQQ).
>
> Are your public Strings null-terminated by default? If not, do you
> intend to provide the strcmp, strcat, and all other standard str*
> functions as part of a String interface?
>
> Do you plan to support raw "char *" pointer or "char &" reference access
> into the String? (QQQ) If yes, do you plan to ensure that the String is
> around for as long as raw data is used?
>
> Do you refcount the public string, the internal buffer, or both? (QQQ --
> some wiki text even implies that refcounted and JIT strings are
> alternative designs, while you are talking about them as working
> together!)

They can, sorry if I got the implication wrong. RefCount would be an
alternative to child-pointers in the buffer. Not the facing string itself,
which may be JIT clones or otherwise.

>
> Does your internal buffer point back to each String using it? (QQQ)
>
> Will your code help to do with efficiently assembling multiple Strings
> together and/or vector I/O? (QQQ)
>
> Will your code be thread-safe?
>
>> Data-wise, String is a triplet (char* data, len, Buf*). Data points
>> into memory managed by the Buf. Multiple strings can share a Buf,
>> possibly at different offsets. Bufs are allocated slightly bigger than
>> needed, and some optimization strategies can be performed to make life
>> easier for the memory manager.
>
>> I'll put the incomplete code somewhere (Launchpad, probably) for
>> everyone to review in a few days at most. So far it seems promising,
>> in about 100 lines of code I have implemented memory management,
>> instantiation, assignment, appending and some debugging (and certainly
>> quite a few bugs).
>

Amos
Received on Tue Aug 26 2008 - 00:31:29 MDT