On Jan 12, 2009, at 4:53 PM, wei wang wrote:
WebKit uses its own string classes instead of using STL string, I
would like to ask why you want to implement your own string classes?
Although webkit uses UTF-16 internally, we can also implement our
own string traits to manipulate UTF-16 char using STL string.
What is your driving force? Are there some advantages of own string
classes over STL string? Thank you.
I think you're asking this question backwards given the history of
WebKit.
Originally, WebKit was started from the KHTML and KJS projects. Those
projects had multiple string classes in their code:
QString, the Qt string class
DOMString, used in the HTML DOM
KJS::UString, used in the JavaScript interpreter
Over time, we've simplified these, eliminated QString, and are still
trying to reduce the number of classes.
If your question is, "Why don't we switch to std::string?", then the
burden of proof goes in the other direction. The burden is on the
person proposing the switch.
The various string classes have many features that std::string does
not have, but it's not as if someone has done this analysis and has a
list of them on hand. I can think of four differences quickl:
WebCore::String is immutable, std::string is not
WebCore::String stores a hash code to make it efficient to use
the string repeatedly as a hash table key
WebCore::String stores only a length, not a capacity, so is
smaller than a string class that also stores a capacity for efficient
resizing
WebCore::String uses high-speed single-thread reference counting
But I'm not sure these are the most important differences; there may
be other more critical ones. Since std::string is part of the standard
library, it's implementation and quality of implementation are likely
to be different on different platforms.
-- Darin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
