.NET 2.0 generic.list.IndexOf doesn't call CompareTo of contained class

[majm]

I'm trying to implement strongly typed lists in the 2.0 framework. I'm
using VS2005 beta 2. So far, System.Collections.Generic.List appears to
be the ideal solution. However, the generic.List.IndexOf function
doesn't appear to be invoking the contained class' CompareTo method. My
understanding is that it should.

The contained class (IssStruct) implements the IComparable and
IComparable<T> interfaces.

However, the List.Sort function does invoke CompareTo, which suggests
that the syntax for the IComparable interface is correct. The same
problem occurs when the class in contained in an ArrayList.

I'm a rank beginner, so feel free to point out anything obvious.

Below are the class declarations. IssStructs is a generic list that
contains IssStruct class instances; UnsafeIssStructs is an ArrayList
that contains IssStruct class instances. They behave the same. IndexOf
does not invoke IssStruct.CompareTo, Sort does invoke
IssStruct.CompareTo.

Muchos thanks to anyone who can offer help.

namespace ClassLibrary1
{

// this is the contained class
public class IssStruct:IComparable<IssStruct>, IComparable
{
public string fStructName;

public IssStruct(string iStructName)
{
fStructName = iStructName;
}

// non-generic version of CompareTo
public int CompareTo(object obj)
{
return fStructName.CompareTo(((IssStruct)obj).fStructName);
}


// generic version of CompareTo
public int CompareTo(IssStruct obj)
{
return fStructName.CompareTo(obj.fStructName);
}


} // end IssStruct, the contained class

// container class. "Has a..." list, not an "Is a..." list
public class IssStructList
{
public List<IssStruct> IssStructs;
public ArrayList UnSafeIssStructs;
public IssStructList()
{
IssStructs = new List<IssStruct>();
UnSafeIssStructs = new ArrayList();
}
}


} // end namespace ClassLibrary1

 

[Christoph Nahr]

I'm trying to implement strongly typed lists in the 2.0 framework. I'm
using VS2005 beta 2. So far, System.Collections.Generic.List appears to
be the ideal solution. However, the generic.List.IndexOf function
doesn't appear to be invoking the contained class' CompareTo method. My
understanding is that it should.

No, it should and does invoke Equals (inherited from Object if not
defined on your element type). IndexOf only needs equality, not
ordering, hence Equals rather than CompareTo.

If you want to do a search that uses the ordering established by
CompareTo you need to call first Sort, then BinarySearch, rather than
IndexOf. BinarySearch will invoke CompareTo to find an element.

 

[Daniel O'Connell [C# MVP]]

No, it should and does invoke Equals (inherited from Object if not
defined on your element type). IndexOf only needs equality, not
ordering, hence Equals rather than CompareTo.

If you want to do a search that uses the ordering established by
CompareTo you need to call first Sort, then BinarySearch, rather than
IndexOf. BinarySearch will invoke CompareTo to find an element.

The docs, however, say that IndexOf uses CompareTo. I've fired off an email
to see if I can find anything out. Digging around it appears that IndexOf
will rely on IEquatable


You've got me. What version of MSDN help are you using?

 

[Christoph Nahr]

The docs, however, say that IndexOf uses CompareTo. I've fired off an email
to see if I can find anything out. Digging around it appears that IndexOf
will rely on IEquatable

Now that you mention it, I do recall that there was such an error in
the Collections docs in one beta version. It's fixed in the current
July CTP, though.

IEquatable defaults to Object.Equals, by the way, although explicitly
implementing the interface should provide better performance for value
types I guess.

 

[Daniel O'Connell [C# MVP]]

Now that you mention it, I do recall that there was such an error in
the Collections docs in one beta version. It's fixed in the current
July CTP, though.

Ya,that appears to be the case. I'm still using beta2 due to my extreme
laziness.

IEquatable defaults to Object.Equals, by the way, although explicitly
implementing the interface should provide better performance for value
types I guess.

Ya, it does seem a little superflous at points, but an examination of the
class shows that that is what it does. I don't recall having ever heard of
it, somehow.

 

[majm]

Thanks, gentlemen. IEquatable did it.