Re: pseudo-specs for a String class

Kinkie,

    Thanks for the details. I agree with most of your design choices so
far. I think you are on the "simple refcounting" side of the
BetterStringBuffer debate so I will let Amos argue for a "internal
buffer knows its users" design as a starting point.

Thank you,

Alex.

On Tue, 2008-08-26 at 09:27 +0200, Kinkie wrote:
> On Mon, Aug 25, 2008 at 10:28 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
> > 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.
>
> Started writing pseudo-c++, then realized it was easier to just code
> the thing and test it out ;)
>
> >> 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).
>
> Ok
>
> > 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?
>
> No, and yes.
>
> > 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?
>
> Will evolve as needed, but at this time I don't plan to offer either.
> I _do_ plan to offer access to the whole string via some kind of
> export() call (two variants, copying and referencing), where the
> latter is frowned upon but since it has potential uses...
>
> > 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!)
>
> Only the internal buffer is refcounted.
> The external strings' storage requirements are very lightweight (2
> pointers and 1 u_int32_t, currently) and thus it makes sense to just
> copy it around.
>
> > Does your internal buffer point back to each String using it? (QQQ)
>
> Shouldn't be needed, so I plan not to.
>
> > Will your code help to do with efficiently assembling multiple Strings
> > together and/or vector I/O? (QQQ)
>
> While I haven't thought of all the corner-cases, no.
> Vector I/O is better handled via a StringList class (which would be
> the heir to WordList)
>
> > Will your code be thread-safe?
>
> As it is now, it's not.
> But if its development doesn't abort, and gets merged, it's still
> quite a valdid starting point as it'd help fix the callers.
> In any case, I believe it would be nice to have two variants of the
> class around, one which is thread-safe and one which is not to be used
> for thread-local storage (but then only the caller knows which is
> which).
>
>
>
Received on Tue Aug 26 2008 - 16:13:26 MDT