[webkit-dev] global new/delete operator in WebKit

Yong Li yong.li.webkit at gmail.com
Wed Jan 13 18:25:59 PST 2010

2010/1/13 Zoltan Horvath <zoltan at webkit.org>

> First, Darin thanks for the summary!
> On Wednesday 13 January 2010, at 20:23, Yong Li wrote:
> > Darin, thank you very much for writing this for my questions. I have
> > another question for "new int[10]", but I guess the answer will be "using
> > Vector instead".
> At the most of the cases WebKit doesn't use arrays like this.

I'm told that fastNewArray<int> is for this.

> > I like the idea that webkit should allow using a custom memory allocator,
> > but I think for most platforms/compilers, overloading global new/delete
> > operators is much better than deriving all classes from FastAllocBase.
> I've
> > seen even the simple utility class "Noncopyable" is derived from
> > FastAllocBase, and the follwing code:
> > class A: Noncopyable
> > must be changed to:
> > class A: public Noncopyable
> > in order to make "new A" accessible.
> As Darin said, there are platforms where you can not orverload global
> new/delete, because it causes problems.

A silly question: will this abnormal problem be fixed some day?

Yes, you have to inherit it publicly, fortunately, the publicly inheriting
> doesn't cause performance or other loss at this cases.
> > As webkit provides the option of using custom allocator with
> FastAllocBase
> > for some special platform/compiler, why does it ban the option of using
> > global new/delete operators on other platforms/compilers? At least, when
> > USE_SYSTEM_MALLOC=1, FastAllocBase should just be empty or redirect to
> > global new/delete in my opinion.
> >
> > -Yong
> We don't ban it yet. :-) What kind of platforms do mean?

Sorry for my English. "does" should be "will". I just think overloading
global new/delete operators is much cleaner than deriving all classes from a
root class and using fastNew<> and fastNewArray<>, unless the platform
doesn't support it, though :)

> Zoltan
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100113/7b9ff80f/attachment.html>

More information about the webkit-dev mailing list