Re: pseudo-specs for a String class

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

-- 
 /kinkie