Closed
Bug 66825
Opened 24 years ago
Closed 24 years ago
nsConsoleService.h uses nsCOMPtr<nsSupportsArray>
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
INVALID
People
(Reporter: dbaron, Assigned: scc)
Details
Attachments
(1 file)
564 bytes,
patch
|
Details | Diff | Splinter Review |
nsConsoleService.h has an nsCOMPtr<nsSupportsArray> member variable. Shouldn't
this be an nsCOMPtr<ns*I*SupportsArray>? I thought nsCOMPtr was supposed to be
used only for interface pointers. (In fact, I thought things like this didn't
compile...) This causes a build warning on mac (blamed to scc) because of the
operator= on nsDerivedSafe.
Assignee | ||
Comment 1•24 years ago
|
||
See
news://news.mozilla.org/scc-3E1526.12182423042001@h-204-29-187-152.netscape.com
An |nsCOMPtr| over a concrete class is now sanctioned when the concrete class
satisfies certain properties. The warning generated by |operator=| is sort of a
false-positive in this case. Yes, interfaces should not define |operator=|,
because that's an invitation to slice. It is valid and reasonable for a leaf
class to define |operator=|, and this is the rare case where someone wants both
at the same time, so my warning fires. ... oh well.
On the other hand, I don't see any reason why this code needs |mListeners| to be
a |nsCOMPtr<nsSupportsArray>|, so, although this is valid, it seems pointless.
I'll attach a patch and test build this on a couple of platforms.
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•24 years ago
|
||
Assignee | ||
Comment 3•24 years ago
|
||
Here's why they do it: they want to call |RemoveElement| instead of first
finding the position, if any, of a matching element, and then calling
|RemoveElementAt|. You can argue that this is right or wrong ... but probably
in a different bug. I'm going to close this one out as INVALID.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•