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!)

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).

Thanks,

Alex.
Received on Mon Aug 25 2008 - 20:28:56 MDT