nsTArray should have SafeElementAt specializations for smart pointers

RESOLVED FIXED in mozilla10

Status

()

Core
XPCOM
P1
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

unspecified
mozilla10
x86
Mac OS X
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

I want to use SafeElementAt sanely on an nsTArray<nsCOMPtr>.
Blocks: 696201
Created attachment 568503 [details] [diff] [review]
Add single-argument SafeElementAt specializations for nsTArrays of smart pointers.
Attachment #568503 - Flags: review?(justin.lebar+bug)
Priority: -- → P1
Why not have a method which returns an nsCOMPtr&, like the two-arg SafeElementAt methods do?  You could just return an empty nsCOMPtr, right?
I could, I suppose, but are there any use cases for that?
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!
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();
  }
> 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.
> 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.
> 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 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...)
Attachment #568503 - Flags: review?(justin.lebar+bug) → review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/058b227d9a07
Flags: in-testsuite-
Whiteboard: [need review]
Target Milestone: --- → mozilla10
https://hg.mozilla.org/mozilla-central/rev/058b227d9a07
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.