Open Bug 307805 Opened 19 years ago Updated 2 years ago

all string classes should allow dependent assignment

Categories

(Core :: XPCOM, defect, P3)

defect

Tracking

()

People

(Reporter: dbaron, Unassigned)

Details

(Whiteboard: [patch])

Attachments

(1 file, 1 obsolete file)

Performance optimization using our string classes would be helped if all string
classes allowed dependent assignment rather than just nsDependent[C]S[ubs]tring.
 Dependent substring assignment would require a check that the class type
supports it -- and fallback to Assign (perhaps with assertion, although I'm
currently thinking without) if it doesn't.  I'd also want a version of
ns[C]AutoString that doesn't imply termination.

Preliminary patch coming.
Attached patch untested patch (obsolete) — Splinter Review
Untested, but compiles through xpcom.
Comment on attachment 195479 [details] [diff] [review]
untested patch

nsString implies termination (remember nsAFlatString).	I think it will be hard
to change that.

It confuses me to see nsTAutoSubstring inherit from nsTAutoString since
nsTAutoString eventually inherits from nsTSubstring.

I sort of think that it's only going to work to allow setting a dependent and
null-terminated buffer on a nsTString.
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.9alpha
(In reply to comment #2)
> nsString implies termination (remember nsAFlatString). I think it will be hard
> to change that.

I didn't change that, with the one exception of nsTAutoSubstring.

> It confuses me to see nsTAutoSubstring inherit from nsTAutoString since
> nsTAutoString eventually inherits from nsTSubstring.
>
> I sort of think that it's only going to work to allow setting a dependent and
> null-terminated buffer on a nsTString.

Yeah, it's odd, but it's also exactly what nsStandardURL::BuildNormalizedSpec
should have been using, and I don't see any other easy way to do it.
Attached patch untested patchSplinter Review
This is tested in that I had it in my tree for months (I'm just removing it now) and it didn't break anything, but I haven't really tested the new stuff.
Attachment #195479 - Attachment is obsolete: true
Assignee: dbaron → nobody
Priority: P1 → P3
Target Milestone: mozilla1.9alpha1 → ---
Component: String → XPCOM
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: