RESOLVED FIXED 32106
Allow custom memory allocation control for the other part of page directory in WebCore
https://bugs.webkit.org/show_bug.cgi?id=32106
Summary Allow custom memory allocation control for the other part of page directory i...
Zoltan Horvath
Reported 2009-12-03 01:18:16 PST
Created attachment 44215 [details] Patch Inherits the following class from Noncopyable because it is instantiated by 'new' and no need to be copyable: class/struct name - instantiated at: WebCore/'location' class ContextMenuClient - (its child class) svg/graphics/SVGImage.cpp:232 class DragClient - (its child class) svg/graphics/SVGImage.cpp:237 class ChromeClient - (its child class) svg/graphics/SVGImage.cpp:243
Attachments
Patch (2.79 KB, patch)
2009-12-03 01:18 PST, Zoltan Horvath
no flags
Patch (2.32 KB, patch)
2009-12-11 04:41 PST, Zoltan Horvath
no flags
WebKit Review Bot
Comment 1 2009-12-03 01:19:10 PST
style-queue ran check-webkit-style on attachment 44215 [details] without any errors.
Eric Seidel (no email)
Comment 2 2009-12-03 13:01:30 PST
Comment on attachment 44215 [details] Patch I'm not sure this is right. 69 class ChromeClient : public Noncopyable { Why should these Abstract Base Classes require that their implementors be non-copyable?
Darin Adler
Comment 3 2009-12-03 14:03:36 PST
(In reply to comment #2) > I'm not sure this is right. > > 69 class ChromeClient : public Noncopyable { > > Why should these Abstract Base Classes require that their implementors be > non-copyable? They should not. I think it’s better to not add any base classes like Noncopyable or FastAllocBase to these abstract base classes.
Zoltan Horvath
Comment 4 2009-12-04 05:44:40 PST
(In reply to comment #2) > (From update of attachment 44215 [details]) > I'm not sure this is right. > > 69 class ChromeClient : public Noncopyable { > > Why should these Abstract Base Classes require that their implementors be > non-copyable? In this case I can inherit SVGImageChromeClient Noncopyable, then ChromeClient don't need to be inherited. At the case of DragClient the instantiation line is: static DragClient* dummyDragClient = new EmptyDragClient; DragClient is abstract and EmptyDragClient is abstract as well. At the case of ContextMenuClient: static ContextMenuClient* dummyContextMenuClient = new EmptyContextMenuClient; The problem is the same as at DragClient.
Darin Adler
Comment 5 2009-12-04 09:17:28 PST
(In reply to comment #4) > At the case of DragClient the instantiation line is: > static DragClient* dummyDragClient = new EmptyDragClient; > > DragClient is abstract and EmptyDragClient is abstract as well. That's incorrect. EmptyDragClient is not abstract -- if it was, the new would not compile. > At the case of ContextMenuClient: > static ContextMenuClient* dummyContextMenuClient = new EmptyContextMenuClient; > > The problem is the same as at DragClient. Same comment.
Zoltan Horvath
Comment 6 2009-12-11 04:41:28 PST
Zoltan Horvath
Comment 7 2009-12-11 04:43:34 PST
You're right! Sorry, I was on the QtWebKit summit, so I can the updated patch now.
WebKit Review Bot
Comment 8 2009-12-11 04:44:59 PST
style-queue ran check-webkit-style on attachment 44670 [details] without any errors.
Zoltan Horvath
Comment 9 2009-12-11 08:18:17 PST
Comment on attachment 44670 [details] Patch Clearing flags on attachment: 44670 Committed r51989: <http://trac.webkit.org/changeset/51989>
Zoltan Horvath
Comment 10 2009-12-11 08:18:27 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.