Bug 6068 - DOMStringImpl needs to be beefed up in preparation for removing QString
Summary: DOMStringImpl needs to be beefed up in preparation for removing QString
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P4 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-13 13:48 PST by Eric Seidel (no email)
Modified: 2007-01-06 10:00 PST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2005-12-13 13:48:09 PST 
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.
Comment 1 Alexey Proskuryakov 2007-01-06 03:24:19 PST 
Eric, is this bug still useful?
Comment 2 Eric Seidel (no email) 2007-01-06 10:00:36 PST 
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.