<div><div>Thank you for replying.</div><div>Well I have another question on using string in WebKit. std::string employs its own memory management policy, but I've found that StringImpl uses 'malloc' and 'free' directly. It doesn't use copy-on-write strategy, even in its copy constructor. So how is StringImpl's performance of memory management compared with std::string. </div>
<div><br></div><div>Thanks again. </div><br><div class="gmail_quote">
On Wed, Jan 14, 2009 at 1:21 AM, Darin Adler <span dir="ltr"><<a href="mailto:darin@apple.com" target="_blank">darin@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Jan 12, 2009, at 4:53 PM, wei wang wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
What is your driving force? Are there some advantages of own string classes over STL string? Thank you.<br>
</blockquote>
<br></div>
I think you're asking this question backwards given the history of WebKit.<br>
<br>
Originally, WebKit was started from the KHTML and KJS projects. Those projects had multiple string classes in their code:<br>
<br>
QString, the Qt string class<br>
DOMString, used in the HTML DOM<br>
KJS::UString, used in the JavaScript interpreter<br>
<br>
Over time, we've simplified these, eliminated QString, and are still trying to reduce the number of classes.<br>
<br>
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.<br>
<br>
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:<br>
<br>
WebCore::String is immutable, std::string is not<br>
WebCore::String stores a hash code to make it efficient to use the string repeatedly as a hash table key<br>
WebCore::String stores only a length, not a capacity, so is smaller than a string class that also stores a capacity for efficient resizing<br>
WebCore::String uses high-speed single-thread reference counting<br>
<br>
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.<br>
<font color="#888888">
<br>
-- Darin<br>
<br>
</font></blockquote></div><br></div>