Open
Bug 307805
Opened 19 years ago
Updated 2 years ago
all string classes should allow dependent assignment
Categories
(Core :: XPCOM, defect, P3)
Core
XPCOM
Tracking
()
NEW
People
(Reporter: dbaron, Unassigned)
Details
(Whiteboard: [patch])
Attachments
(1 file, 1 obsolete file)
19.45 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•19 years ago
|
||
Untested, but compiles through xpcom.
Comment 2•19 years ago
|
||
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.
Reporter | ||
Updated•19 years ago
|
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.9alpha
Reporter | ||
Comment 3•19 years ago
|
||
(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.
Reporter | ||
Comment 4•18 years ago
|
||
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
Updated•12 years ago
|
Assignee: dbaron → nobody
Priority: P1 → P3
Target Milestone: mozilla1.9alpha1 → ---
Assignee | ||
Updated•4 years ago
|
Component: String → XPCOM
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•