1494765 - Allow assignment from an nsCOMPtr of a related type

Status: RESOLVED FIXED

(Core :: XPCOM, enhancement, P3)

Description

[Andrew McCreight [:mccr8]]

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.

Comment 1

[Andrew McCreight [:mccr8]]

I don't think the static_asserts are really needed, but other similar code had them so I figured I'd play it safe.

Comment 2

[Andrew McCreight [:mccr8]]

Attachment: Bug 1494765 - Allow assignment from an nsCOMPtr of a related type

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 3

[Nathan Froyd [:froydnj]]

Comment on attachment 9013019 [details]
Bug 1494765 - Allow assignment from an nsCOMPtr of a related type

Nathan Froyd [:froydnj] has approved the revision.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cb01170872de
Allow assignment from an nsCOMPtr of a related type r=froydnj

Comment 5

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/825f10de7839
Backed out changeset cb01170872de for bustages on nsCOMPtr.h. CLOSED TREE

Comment 6

[Andrew McCreight [:mccr8]]

Looks like I forgot MOZ_IMPLICIT for the new move ctor.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3a9818cd5ffa
Allow assignment from an nsCOMPtr of a related type r=froydnj

Comment 8

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/3a9818cd5ffa