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: