696195 - nsTArray should have SafeElementAt specializations for smart pointers

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P1)

Description

[Boris Zbarsky [:bzbarsky]]

I want to use SafeElementAt sanely on an nsTArray<nsCOMPtr>.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Add single-argument SafeElementAt specializations for nsTArrays of smart pointers.

Comment 2

[Justin Lebar (not reading bugmail)]

Why not have a method which returns an nsCOMPtr&, like the two-arg SafeElementAt methods do?  You could just return an empty nsCOMPtr, right?

Comment 3

[Boris Zbarsky [:bzbarsky]]

I could, I suppose, but are there any use cases for that?

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 568503 [details] [diff] [review]
Add single-argument SafeElementAt specializations for nsTArrays of smart pointers.

Instead of hardcoding nsCOMPtr and nsRefPtr you could use a template template parameter, see for example:

https://mxr.mozilla.org/mozilla-central/source/dom/workers/WorkerPrivate.cpp#131

The syntax is horrendous, but it works!

Comment 5

[Justin Lebar (not reading bugmail)]

It just seems kinda weird to me that the nsTArray interface uses nsCOMPtr<T>& and nsCOMPtr<T>*, except SafeElementAt, which returns T*.

For a use-case, how about something like:

  nsCOMPtr<Foo>& foo = arr.SafeElementAt(i);
  if (foo && ...) {
    // null out the element in the array, but don't remove it, because that'd be expensive.
    return foo.forget();
  }

Comment 6

[Boris Zbarsky [:bzbarsky]]

> The syntax is horrendous, but it works!

It also seems like it could produce specializations for things that we may not want them for (e.g. nsAutoPtr).  I'd rather not do that, I think.....  Justin?

> For a use-case, how about something like:

OK, sold.

Comment 7

[Justin Lebar (not reading bugmail)]

> Instead of hardcoding nsCOMPtr and nsRefPtr you could use a template template parameter

I don't think that works here.  SwapToISupportsArray will take any Foo<T> class.  But we're using template specialization so that SafeElementAt(i) only exists when the T in nsTArray<T> is a pointer, nsCOMPtr, or nsRefPtr.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> For a use-case, how about something like:

Actually, I don't think that works; that involves returning a non-const reference, which can't be created from a temporary.

Comment 9

[Justin Lebar (not reading bugmail)]

Comment on attachment 568503 [details] [diff] [review]
Add single-argument SafeElementAt specializations for nsTArrays of smart pointers.

This looks like the only sane way to do it.  (Unless you just want to punt on the single-argument SafeElementAt for smart pointers and call the two-argument version...)

Comment 10

[Boris Zbarsky [:bzbarsky]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/058b227d9a07

Comment 11

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/058b227d9a07