<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&#39;ve found that StringImpl uses &#39;malloc&#39; and &#39;free&#39; directly. It doesn&#39;t use copy-on-write strategy, even in its copy constructor. So&nbsp;how is StringImpl&#39;s performance of memory management compared with std::string.&nbsp;</div>
<div><br></div><div>Thanks again.&nbsp;</div><br><div class="gmail_quote">
On Wed, Jan 14, 2009 at 1:21 AM, Darin Adler <span dir="ltr">&lt;<a href="mailto:darin@apple.com" target="_blank">darin@apple.com</a>&gt;</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&#39;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>
 &nbsp; &nbsp;QString, the Qt string class<br>
 &nbsp; &nbsp;DOMString, used in the HTML DOM<br>
 &nbsp; &nbsp;KJS::UString, used in the JavaScript interpreter<br>
<br>
Over time, we&#39;ve simplified these, eliminated QString, and are still trying to reduce the number of classes.<br>
<br>
If your question is, &quot;Why don&#39;t we switch to std::string?&quot;, 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&#39;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>
 &nbsp; &nbsp;WebCore::String is immutable, std::string is not<br>
 &nbsp; &nbsp;WebCore::String stores a hash code to make it efficient to use the string repeatedly as a hash table key<br>
 &nbsp; &nbsp;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>
 &nbsp; &nbsp;WebCore::String uses high-speed single-thread reference counting<br>
<br>
But I&#39;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&#39;s implementation and quality of implementation are likely to be different on different platforms.<br>

<font color="#888888">
<br>
 &nbsp; &nbsp;-- Darin<br>
<br>
</font></blockquote></div><br></div>