【问题标题】:Enumerable.Except with IEqualityComparerEnumerable.Except 与 IEqualityComparer 除外
【发布时间】:2014-10-14 02:59:41
【问题描述】:

我有两个字符串数组,newArray 和 oldArray,我想使用 Enumberable.Except 方法来删​​除 newArray 中同时也在 oldArray 中的所有项目,然后将结果写入 csv 文件。

但是,我需要使用自定义比较器来检查格式相似性(如果一个数组中有换行符而不是另一个,我不希望将此项写入文件)。

我现在的代码:

        string newString = File.ReadAllText(csvOutputFile1);
        string[] newArray = newString.Split(new string[] {sentinel}, StringSplitOptions.RemoveEmptyEntries);
        string oldString = File.ReadAllText(csvOutputFile2);
        string[] oldArray = oldString.Split(new string[] { sentinel }, StringSplitOptions.None);

        IEnumerable<string> differnceQuery = newArray.Except(oldArray, new Comparer());

        using (var wtr = new StreamWriter(diffFile))
        {
            foreach (var s in differnceQuery)
            {
                wtr.WriteLine(s.Trim() + "#!#");
            }
        }

和自定义比较器类:

class Comparer : IEqualityComparer<string>
{
    public bool Equals(string x, string y)
    {
        x = x.ToString().Replace(" ", "").Replace("\n", "").Replace("\r", "");
        y = y.ToString().Replace(" ", "").Replace("\n", "").Replace("\r", "");
        if (x == y)
            return true;
        else
            return false;
    }
    public int GetHashCode(string row)
    {
        int hCode = row.GetHashCode();
        return hCode;
    }
}

生成的文件没有省略两个数组之间的格式差异项。因此,尽管它捕获了 newArray 但不在 oldArray 中的项目(就像它应该的那样),但它也会放入仅因 \n 或其他原因而不同的项目,即使在我的自定义比较器中我正在删除它们。

我真正不明白的是,当我调试并单步执行代码时,我可以看到在我的自定义比较器类中分析的每一对项目,但只有当它们是相等的时。例如,如果字符串“This is\nthe 1st term”在 newArray 中,而字符串“This is the first array”在 oldArray 中,调试器甚至不会进入比较器类,而是直接跳转到我的 writeline 部分主类中的代码。

【问题讨论】:

标签: c# ienumerable except iequalitycomparer


【解决方案1】:

简单地说:您的哈希码没有正确反映您的相等方法。像"a b c""abc" 这样的字符串会从GetHashCode 返回不同的值,所以它永远不会绕过 来测试EqualsGetHashCode 必须为任何两个可能相等的值返回相同的结果。然而,两个相等的字符串没有必要返回不同哈希码(尽管它是非常需要,否则一切都会进入同一个哈希桶)。

你可以使用:

// warning: probably not very efficient
return x.Replace(" ", "").Replace("\n", "").Replace("\r", "").GetHashCode();

但这看起来相当昂贵(很可能会一直生成垃圾字符串)

【讨论】:

  • 谢谢马克。这行得通,但你是对的,效率不高。现在必须这样做,谢谢!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-12-11
  • 2011-03-20
  • 1970-01-01
  • 1970-01-01
  • 2010-09-30
  • 1970-01-01
相关资源
最近更新 更多