[Webkit-unassigned] [Bug 142349] Use std::unique_ptr instead of PassOwnPtr|OwnPtr for ResourceRequest

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=142349

--- Comment #4 from Joonghun Park <jh718.park at samsung.com> ---
(In reply to comment #2)
> Comment on attachment 247959 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=247959&action=review
> 
> > Source/WebCore/loader/WorkerThreadableLoader.cpp:100
> > -    CrossThreadResourceRequestData* requestData = request.copyData().leakPtr();
> > +    auto requestData = request.copyData().release();
> >      StringCapture capturedOutgoingReferrer(outgoingReferrer);
> >      m_loaderProxy.postTaskToLoader([this, requestData, options, capturedOutgoingReferrer](ScriptExecutionContext& context) {
> >          ASSERT(isMainThread());
> >          Document& document = downcast<Document>(context);
> >  
> > -        OwnPtr<ResourceRequest> request = ResourceRequest::adopt(adoptPtr(requestData));
> > +        std::unique_ptr<ResourceRequest> request = ResourceRequest::adopt(std::unique_ptr<CrossThreadResourceRequestData>(requestData));
> 
> Is there no way to pass the unique_ptr to the lambda? Here’s a thread about
> it: <http://stackoverflow.com/questions/8640393/move-capture-in-lambda> and
> <http://stackoverflow.com/questions/8236521/how-to-capture-a-unique-ptr-into-
> a-lambda-expression>
> 
> This is a case where clarity clearly suffers. It was easy to see how the
> leakPtr and adoptPtr matched up. It’s not nearly was easy to spot the
> explicit std::unique_ptr construction and see that it matches up with the
> release() call. Seems like we should make an adopt function for unique_ptr
> in WTF so this idiom is more readable. I think C++14 will let us handle this
> in a cleaner way passing the unique_ptr through the lambda.

Thank you for your kind comment! It seems that it is needed for me to see this subject more deeper. :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150305/2bde4fd4/attachment-0002.html>