<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks for the response. I'm sorry, and perhaps I misunderstand, but I
believe your statement about inline operator new is incorrect. Unless I
misunderstand you, what you say is not supported by any existing
compiler nor is it supported by the C++ language standard. In summary,
the 'inline' keyword does not negate or obviate the One Definition
Rule. You can demonstrate the problem with the code below. Feel free to
correct any misunderstanding that I may have of your explanation. <br>
<br>
I do not mean to criticize WebKit. We think it is a great thing which
in general is surprisingly well coded. We would love to work with any
resolution which has the desired effect in the way of memory management.<br>
<br>
The error you get:<small><font face="Courier New"><br>
</font></small>
<blockquote><small><font face="Courier New">SomeLib.lib: error LNK2005:
"void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already
defined in main.obj</font></small><br>
  <small><font face="Courier New">SomeLib.lib: error LNK2005: "void
__cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in
main.obj</font></small><br>
</blockquote>
Source code:<small><font face="Courier New"><br>
</font></small>
<blockquote><small><font face="Courier New">// Main.cpp </font></small><br>
  <small><font face="Courier New">#include &lt;stdlib.h&gt;</font></small><br>
  <small><font face="Courier New">extern void DoSomething();</font></small><br>
  <br>
  <small><font face="Courier New">void* operator new(size_t s)&nbsp;&nbsp;&nbsp; {
return malloc(s); }</font></small><br>
  <small><font face="Courier New">void&nbsp; operator delete(void* p)&nbsp; {
free(p); }</font></small><br>
  <small><font face="Courier New">void* operator new[](size_t s)&nbsp; {
return malloc(s); }</font></small><br>
  <small><font face="Courier New">void&nbsp; operator delete[](void* p){
free(p); }</font></small><br>
  <br>
  <small><font face="Courier New">int main(int, char*[]) {</font></small><br>
  <small><font face="Courier New">&nbsp;&nbsp;&nbsp; void* p = malloc(10);</font></small><br>
  <small><font face="Courier New">&nbsp;&nbsp;&nbsp; free(p);</font></small><br>
  <small><font face="Courier New">&nbsp;&nbsp;&nbsp; DoSomething();</font></small><br>
  <small><font face="Courier New">&nbsp;&nbsp;&nbsp; return 0;</font></small><br>
  <small><font face="Courier New">}</font></small><br>
  <br>
  <small><font face="Courier New">// SomeLib.cpp - compiled in a
separate lib </font></small><br>
  <small><font face="Courier New">#include &lt;stdlib.h&gt;</font></small><br>
  <br>
  <small><font face="Courier New">inline void* operator new(size_t
s)&nbsp;&nbsp;&nbsp;&nbsp; { return malloc(s); }</font></small><br>
  <small><font face="Courier New">inline void&nbsp; operator delete(void* p)
&nbsp; { free(p); }</font></small><br>
  <small><font face="Courier New">inline void* operator new[](size_t s)
&nbsp; { return malloc(s); }</font></small><br>
  <small><font face="Courier New">inline void&nbsp; operator delete[](void*
p) { free(p); }</font></small><br>
  <br>
  <small><font face="Courier New">void DoSomething(){</font></small><br>
  <small><font face="Courier New">&nbsp;&nbsp;&nbsp; void* p = malloc(10);</font></small><br>
  <small><font face="Courier New">&nbsp;&nbsp;&nbsp; free(p);</font></small><br>
  <small><font face="Courier New">}</font></small><br>
</blockquote>
Thanks.<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:513CF0AA-2C6F-4B7A-B94D-5D4C4B553B09@apple.com"
 type="cite">On 03/06/2008, at 21:13, Paul Pedriana wrote:
  <br>
  <br>
  <blockquote type="cite">Thanks for the info. IMHO, tcmalloc is not
appropriate for console,
    <br>
embedded, and mobile platforms. It trades space for speed, and that's
    <br>
the opposite of what you want outside the desktop. This is why the
Nokia
    <br>
S60 people replaced tcmalloc, for example.
    <br>
  </blockquote>
  <br>
As far as I can tell, Nokia's S60 port predates the adoption of
tcmalloc by WebKit.&nbsp; The code in their latest svn.webkit.org source
tree contains a variant of dlmalloc that was used up until Safari 2.0,
though I have not checked to see whether it is compiled in to their
build.&nbsp; That said, it is obvious that the space vs. speed tradeoffs
differ between devices, and that flexibility in the memory allocator
used is desirable.
  <br>
  <br>
  <blockquote type="cite">Unfortunately, overriding operator new and
delete does not do the right
    <br>
thing. These operators are application-global functions and when you
    <br>
redirect them for one library you are thus redirecting them for the
    <br>
entire rest of the app. Needless to say, that is a bad thing. In
console
    <br>
and embedded development, as I note in the aforementioned paper, it is
    <br>
typically verboten for a library to use operator new/delete.
    <br>
  </blockquote>
  <br>
On the platforms with which I am familiar, the implementation that I
linked to has no effect outside of the library in which it is defined.&nbsp;
I've not worked with consoles or embedded devices so the toolchain and
environment may differ there, but I would be a little surprised to see
an inline function that is implemented in a header become visible to an
object file that did not include the header.
  <br>
  <br>
  <br>
  <blockquote type="cite">Neither will you see professional commercial
software do this.
    <br>
  </blockquote>
  <br>
  <br>
  <blockquote type="cite">It's also a problem to have any calls to
system malloc at all, because often on
    <br>
these platforms there is little or no memory available, as the
    <br>
application has taken it all to distribute to private heaps as per
their
    <br>
budget.
    <br>
  </blockquote>
  <br>
The direct calls are few and far between.&nbsp; They can easily be evaluated
to determine which, if any, have a legitimate need to call the system
allocator and the remainder updated to use "fastMalloc" / "fastFree".&nbsp;
I'd gladly review a patch that moves in this direction.
  <br>
  <br>
  <blockquote type="cite">One simple and effective way to solve this
problem is to provide a
    <br>
memory config header file which defines macros or templates which
    <br>
replace new/delete, malloc/free. Instead of calling global new, WC_NEW
    <br>
(e.g.) is called instead.
    <br>
  </blockquote>
  <br>
How does this differ from FastMalloc.h and "fastMalloc" / "fastFree"
that I described in my previous email, other than addressing the
perceived problem with "operator new" / "operator delete"?
  <br>
  <br>
  <br>
  <blockquote type="cite">This is how commercial-quality software is
done
    <br>
  </blockquote>
  <br>
  <br>
Kind regards,
  <br>
  <br>
Mark Rowe
  <br>
  <br>
</blockquote>
<br>
</body>
</html>