我最近正在使用一个DateTime对象，并写了这样的东西:
DateTime dt = DateTime.Now;
dt.AddDays(1);
return dt; // still today's date! WTF?
AddDays()的智能感知文档说它在日期后添加了一天，但它并没有这样做——它实际上返回了一个添加了一天的日期，所以你必须这样写:
DateTime dt = DateTime.Now;
dt = dt.AddDays(1);
return dt; // tomorrow's date
这个问题以前已经困扰过我很多次了，所以我认为将最糟糕的c#陷阱分类会很有用。
当前回答
在调试环境中求值时，base关键字不能按预期工作:方法调用仍然使用虚拟分派。
当我偶然发现它时，我浪费了很多时间，我以为我遇到了CLR时空中的某种裂缝，但我后来意识到这是一个已知的(甚至有点故意的)bug:
http://blogs.msdn.com/jmstall/archive/2006/06/29/funceval-does-virtual-dispatch.aspx
其他回答
重载==操作符和非类型化容器(数组列表、数据集等):
string my = "my ";
Debug.Assert(my+"string" == "my string"); //true
var a = new ArrayList();
a.Add(my+"string");
a.Add("my string");
// uses ==(object) instead of ==(string)
Debug.Assert(a[1] == "my string"); // true, due to interning magic
Debug.Assert(a[0] == "my string"); // false
解决方案?
总是使用字符串。当比较字符串类型时等于(a, b) 使用像List<string>这样的泛型来确保两个操作数都是字符串。
在虚方法中使用默认参数
abstract class Base
{
public virtual void foo(string s = "base") { Console.WriteLine("base " + s); }
}
class Derived : Base
{
public override void foo(string s = "derived") { Console.WriteLine("derived " + s); }
}
...
Base b = new Derived();
b.foo();
输出: 派生的基础
private int myVar;
public int MyVar
{
get { return MyVar; }
}
心想。你的应用在没有堆栈跟踪的情况下崩溃了。这种事经常发生。
(请注意getter中的大写MyVar而不是小写MyVar。)
LinqToSql批处理速度随着批处理大小的平方而变慢
以下是我探索这个问题的问题(和答案)。
In a nutshell, if you try to build up too many objects in memory before calling DataContext.SubmitChanges(), you start experiencing sluggishness at a geometric rate. I have not confirmed 100% that this is the case, but it appears to me that the call to DataContext.GetChangeSet() causes the data context to perform an equivalence evaluation (.Equals()) on every single combination of 2 items in the change set, probably to make sure it's not double-inserting or causing other concurrency issues. Problem is that if you have very large batches, the number of comparisons increases proportionately with the square of n, i.e. (n^2+n)/2. 1,000 items in memory means over 500,000 comparisons... and that can take a heckuva long time.
为了避免这种情况，您必须确保对于预计有大量项目的任何批处理，您都在事务边界内完成整个工作，在创建每个项目时保存它，而不是在最后进行一次大保存。
Dictionary<，>: "返回项的顺序未定义"。这很可怕，因为它有时会咬你一口，但会对其他人起作用，如果你只是盲目地认为Dictionary会表现得很好(“为什么不呢?”我想，是List做的”)，在你最终开始质疑你的假设之前，你真的必须深入了解它。
(这里也有类似问题。)
