Draft: PSA: Start using std::unique_ptr in Blink!

[Yuta Kitamura]

[I'm planning to announce the general availability of std::unique_ptr in Blink soonish (tomorrow?). The below is my draft announcement; please proofread and give me your feedback!]

Hi Blink devs,

Over the past weeks, Mikhail from Intel and I were fixing various WTF components so they can accept move-only (non-copyable but movable) objects. The work is now complete; you can now put your move-only stuff into Vector, HashSet or WTF::bind()!

With regard to this, I'm happy to announce the general availability of std::unique_ptr in Blink! You are now encouraged to use std::unique_ptr in new code, as a replacement for OwnPtr.

If you notice anything that isn't compatible with std::unique_ptr, please file a bug, assign it to me and keep using OwnPtr meanwhile.

Quick Transition Guide

There are a few syntactic differences in the usage of OwnPtr and std::unique_ptr. See the transition guide to kick-start yourself.

Q & A

Q1: Do I have to convert the existing use of OwnPtrs to std::unique_ptrs now?

A1: No, you don't have to do that yet. We are planning to "degrade" (in a sense) the functionality of OwnPtr gradually, to make OwnPtrs and PassOwnPtrs behave as exactly as std::unique_ptrs. After that work is completed, it'll be much easier to transition, and I'll call for help for mass conversions at around that time.

Q2: Can I put std::unique_ptrs in a HashSet or the key part of a HashMap?

A2: Yup. Default hash functions and hash traits for std::unique_ptr are defined, so these containers should work just as you put OwnPtrs.

Q3: What about our Class::create() idiom? Can we use Chromium's WrapUnique() or MakeUnique() instead of Class::create()?

A3: This is a pretty involved topic. WrapUnique()/MakeUnique() can be better than Class::create() in certain situations, but they come with some shortcomings. A conclusion has not reached yet. I will send out another email to blink-dev later to discuss the issue in detail.

Q4: Does WTF provide Chromium's WrapUnique() or MakeUnique() equivalents?

A4: It currently doesn't, but I'm planning to provide at least either of them. I'm currently leaning towards providing just MakeUnique(), since that is from a standard which we will eventually adopt. MakeUnique() in Chromium is currently under review, so we can't use it right away, though.

Credits

Kudos to mikhail.p...@intel.com for his work on move semantics support in several WTF containers.

The rest is me ;)

That's it! Thanks for reading thus far. If you have any questions, please let us know.

Yuta, on behalf of Architecture Team

[Kentaro Hara]

LGTM

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAFJcur9HSqCy7GWtFGEoCtte7Pifb%3DRiYH3otRh%2BznQOUDAyaw%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[Jeremy Roman]

nit: suggesting

owned = std::unique_ptr<T>()

as an alternative to reset() seems odd to me, as I think I might write "owned.reset()" or "owned = nullptr", but default-constructing a unique_ptr to do this seems awkward to me.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jwiMPsLHg8zTrM34usWYTKUhRzEdHrjYe-xzi7-paMx8Q%40mail.gmail.com.

[Jeremy Roman]

Oh, one more question: how long is the work mentioned in A1 expected to take? I'd prefer not to have a long period of time where both OwnPtr<T> and std::unique_ptr<T> appear in the codebase. If it's expected to take a long time, perhaps encouraging use of std::unique_ptr should be delayed until (Pass)?OwnPtr<T> are about to be removed.

But in general I'm quite happy about this direction. :)

[Yuta Kitamura]

On Tue, Apr 5, 2016 at 12:03 AM, Jeremy Roman <jbr...@chromium.org> wrote:

nit: suggesting

owned = std::unique_ptr<T>()

as an alternative to reset() seems odd to me, as I think I might write "owned.reset()" or "owned = nullptr", but default-constructing a unique_ptr to do this seems awkward to me.

Yeah, I think that's better. I'll fix the documentation soon.

 

[Yuta Kitamura]

On Tue, Apr 5, 2016 at 12:06 AM, Jeremy Roman <jbr...@chromium.org> wrote:

Oh, one more question: how long is the work mentioned in A1 expected to take? I'd prefer not to have a long period of time where both OwnPtr<T> and std::unique_ptr<T> appear in the codebase. If it's expected to take a long time, perhaps encouraging use of std::unique_ptr should be delayed until (Pass)?OwnPtr<T> are about to be removed.

But in general I'm quite happy about this direction. :)

My current estimate is it will take ~1 month to match the behavior of OwnPtr/PassOwnPtr with std::unique_ptr's. (But I'm known to be pretty bad at estimating things, so that might be 2 months. ;) )

Essentially, what I'm going to do is to just add std::move() in many many places; OwnPtr/PassOwnPtr uses copying as means of transferring ownership, and that will become std::move() in the move semantics world.