Re: SqString

Alex Rousskov wrote:
> On Thu, 2007-05-24 at 11:19 +0200, Henrik Nordstrom wrote:
>> Should we back out SqString for now until the implicit cast issues have
>> been analyzed in more detail, or try fixing it somehow for the 3.0
>> release?
>>
>> http://www.squid-cache.org/bugs/show_bug.cgi?id=1970
>>
>> My vote is to defer the SqString change to 3.1, or at least after 3.0
>> has been branched from HEAD.
>>
>> Reasoning: More work is required to polish it, and it doesn't really add
>> anything to the 3.0 release (beyond the bugfixes it triggered
>> indirectly), mainly preparation for future work.
>
> I still think SqString "API" changes should not be in 3.0, but I do not
> have a strong opinion and do not want to be the one backing them out.
>
> We could adopt a middle-ground solution. The changes limited to renaming
> String methods to match std::string API can stay. The changes
> introducing new operators, conversions, or methods should be postponed
> until v3.1. Same for changes in the code that uses Strings: renaming is
> fine, rearranging and optimizing things is not.
>
> HTH,
>
> Alex.
>

I have just been experimenting with a few options short of a full backout.

My initial idea of dropping the constructor drags the changes into areas
the initial patch didn't touch. No go there.

I have had some success dropping the str* overloading entirely.
Replacing it all with a single casting operator which explicitly forces
the magic casts to reverse from the expensive copy 'up' toward string
into a cheap cast 'down' to a c_str() call.

Keep in mind this c_str() call being explicitly done all over squid at
present anyway. The only known risk is a buffer over- or under-run which
would occur anyway if the alternative explicit c_str() call was coded.

*please* test it this time. patch is attached or checkout and test the
squid3 branch labeled 'ayjwork'.

Alex: I'd particularly like a OK/DIES from you and your ICAP testing.

Amos