However, I am not aware of any platforms where an overridden operator new would have effect across a DLL boundary ...

A DLL on Windows is treated rather like an EXE for the purposes of linkage. However, DLLs are a Windows-specific feature which don't exist on other platforms, though some desktop platforms have similar 'shared library' concepts. Some gaming and embedded platforms have the concept of shared libraries, though they often don't treat them as independently linkable units like Windows DLLs but instead think of them more like a code overlay within the current process and thus share symbols.

As I understand the LGPL (an abbreviated description: http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License), statically linking is fine. What matters is that derivative software be available in linkable library form, and that explicitly includes statically linked software. This makes sense because many platforms other than Unix and Windows platforms don't have the concept of dynamic linking, and it wouldn't make sense for LGPL to apply to some platforms and not others. The key point of LGPL relative to GPL is to recognize the concept of libraries as opposed to applications.
So far, we've been quite happy using platform tools for memory debugging. Personally, I do not think that explicitly tagging memory in this way would be cost-effective, although this is certainly not out of the question.
I understand. It's just one approach, and a good set of stack/module trawling tools can help achieve much the same thing. My main point is of course to be able to control where memory comes from, and this merely provides an easy means of achieving some explicit metrics functionality. It's been useful in the gaming industry as a complement to the other usual tools.

Thanks.

Paul


On Jun 4, 2008, at 9:58 AM, Paul Pedriana wrote:

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.
You are right that the presence of a declaration or inlining do not affect the behavior of overridden global operator new, other than via possible implementation-specific quirks (because compilers are not required to detect ODF violations).

However, I am not aware of any platforms where an overridden operator new would have effect across a DLL boundary (note that the C++ standard doesn't talk about dynamic linking at all). So, this is only an issue if you link WebCore to your application statically, or specifically export operator new from your DLL. There is no need to do the latter, and the former sounds like a violation of LGPL to me. If your platform does not support dynamic linking, or you cannot use it for some other reason, you may want to investigate the legal feasibility of using LGPL-licensed code in your projects before pursuing technical solutions.

Thus you could use WC_NEW("WebCore/page") to flag the memory
as belonging to that subsystem. This is invaluable in identifying
memory, producing subsystem metrics, optimizing memory coherence, and
deducing memory leaks (though other means also help find leaks).

So far, we've been quite happy using platform tools for memory debugging. Personally, I do not think that explicitly tagging memory in this way would be cost-effective, although this is certainly not out of the question.

- WBR, Alexey Proskuryakov



_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to