Bug 6068
| Summary: | DOMStringImpl needs to be beefed up in preparation for removing QString | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | ap |
| Priority: | P4 | ||
| Version: | 420+ | ||
| Hardware: | Mac | ||
| OS: | OS X 10.4 | ||
Eric Seidel (no email)
DOMStringImpl needs to be beefed up in preparation for removing QString
One of our eventual goals is to remove the use of QString throughout our engine. Currently we have at
least 3 common string classes in WebCore: UString (UTF16), DOMString (UTF16), and QString (UTF8). We
do some operations using each. Conversions between the three can be painful. Most painful however is
the repeated conversion between DOMString and QString, as we have to pay the UTF16<->UTF8 encoding
change cost every time.
One of the eventual goals is to remove the use of QString and instead use DOMString or DOMStringImpl
(wrapped in a SharedPtr). This bug tracks that progress.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Eric, is this bug still useful?
Eric Seidel (no email)
Nah. I think there are already bugs about making DOMString::append fast, or possibly even adding duel-encoding-storage support to DOMString like DeprecatedString (formerly QString) has.