Re: pseudo-specs for a String class

2008/8/27 Amos Jeffries <squid3_at_treenet.co.nz>:
>> But you miss my earlier point - would you use _string_ for storing the
>> _reply_ information in the memory store? The reply headers? sure. The
>> reply body chunks? :)

> I see no reason why not. Beyond the size argument. Which is a red-herring
> anyway. It's only the classical std:string functions which won't work on
> binary.
>
> And whose to say we won't one day want to do object byte-wise body chunk
> comparisons with something exactly equivalent to String::strcmp()?
> (ie storeurl_rewrite object equivalence validation)

strcmp() is fine for comparing NUL terminated sequences of bytes.
Using it to compare differently encoded -strings- however is a
different kettle of fish.
I'm thinking for the future if you want to support stuff like
charsets, you don't want all of that complexity in the way for the
cases where its not needed.

> Or supply range requests using likewise, something exactly equivalent to
> String::substr(A,B) and String::strlen()?

There's nothing stopping you from implementing subregion matching on a
memory region or creating a subregion from another subregion. It'll be
a byte comparison, like the C "strcmp()" is, save the NUL termination.

"String length" for the ASCII NUL-terminated string is different from
"string length" over the same region of memory if its unicode encoded,
for example.

In any case, if you have some reply data which you want to do -string-
operations/comparisons on, versus comparing raw memory like the C
string API mostly implements for ASCII, NUL-terminated strings, I
think you should just create a String which references the region of
memory you're interested in. That initialization will be very cheap.

I'm just trying to think ahead and save ourselves the bother if and
when someone wants to sprinkle character set awareness in various
string related places.

Adrian
Received on Wed Aug 27 2008 - 14:46:56 MDT