Closed Bug 1494765 Opened Last year Closed Last year
Allow assignment from an ns
COMPtr of a related type
46 bytes, text/x-phabricator-request
|Details | Review|
In bug 1493737, Olli didn't like that I was using the ctor and not an assignment operator in cases like this: nsCOMPtr<Bar> y; [...] nsCOMPtr<Foo> x(y); where Bar is a subclass of Foo. I was doing this because it doesn't actually work to do |nsCOMPtr<Foo> x = y;|, but that's just because nsCOMPtr<> is missing an operator= overload for this case, which RefPtr<> has, so I'll add it, then fix up my patch for the other bug.
I don't think the static_asserts are really needed, but other similar code had them so I figured I'd play it safe.
This adds support for conversion from nsCOMPtr<A> to nsCOMPtr<B> when A is a subclass of B. There's no reason to not allow this, and RefPtr already supports this.
Comment on attachment 9013019 [details] Bug 1494765 - Allow assignment from an nsCOMPtr of a related type Nathan Froyd [:froydnj] has approved the revision.
Attachment #9013019 - Flags: review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/cb01170872de Allow assignment from an nsCOMPtr of a related type r=froydnj
Backout by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/825f10de7839 Backed out changeset cb01170872de for bustages on nsCOMPtr.h. CLOSED TREE
Looks like I forgot MOZ_IMPLICIT for the new move ctor.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/3a9818cd5ffa Allow assignment from an nsCOMPtr of a related type r=froydnj
You need to log in before you can comment on or make changes to this bug.