often faster.
for (Iterator i = c.iterator(); i.hasNext(); ) {
modified |= remove(i.next());
}
return modified;
}
Jeff
De : Jason Mehrens
À : mike.dui...@oracle.com; jeffh...@rocketmail.com
Cc : core-libs-dev@openjdk.java.net
Envoyé le : Jeu 14 juillet
On Jul 13 2011, at 15:19 , Jason Mehrens wrote:
> worst case AbstractCollection.isEmpty could be O(N).
> JDKs 5 and 6 shipped with two collections (CHM views) that had O(N) isEmpty
> methods.
This is very interesting. The common wisdom has been that size() should be
avoided because of O(>1)
ase/view_bug.do?bug_id=5028425
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6633605
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6250140
Jason
> Subject: Re: AbstractCollection.removeAll(Collection) and
> AbstractSet.removeAll(Collection)
> From: mike.dui...@oracle.com
{
> i.remove();
> modified = true;
> if (--toRemove == 0) {
> break;
> }
>}
> }
> } else {
> // "c" might contain more than Integer.MAX_VALUE
> /
// "c" might contain more than Integer.MAX_VALUE
// elements, so we can't break early.
for (Iterator i = iterator(); i.hasNext(); ) {
if (c.contains(i.next())) {
i.remove();
modified = true;
}
}
}
}
r
It doesn't work because the complexity of size() can be O(n).
In my opinion, only the checks for emptyness are Ok.
Rémi
On 07/13/2011 05:40 PM, Sebastian Sickelmann wrote:
Jeff Hain wrote:
Hello.
I have some remarks about the methods named in the subject (JDK 6u26, JDK
7b147).
1) Ab
Jeff Hain wrote:
> Hello.
>
> I have some remarks about the methods named in the subject (JDK 6u26, JDK
> 7b147).
>
>
> 1) AbstractCollection.removeAll(Collection)
> This method could return immediately if the specified collection is
> empty,
> not to iterate uselessly over all "this", or
