Closed
Bug 66825
Opened 24 years ago
Closed 23 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•23 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•23 years ago
|
||
Assignee | ||
Comment 3•23 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: 23 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•