我收集了一些极端案例和脑筋急转弯，总是想听到更多。这个页面只涵盖了c#语言的一些细节，但我也发现了。net核心的东西也很有趣。例如，这里有一个没有在页面上，但我觉得不可思议:
string x = new string(new char[0]);
string y = new string(new char[0]);
Console.WriteLine(object.ReferenceEquals(x, y));
我希望输出False -毕竟，“new”(具有引用类型)总是创建一个新对象，不是吗?c#和CLI的规范都表明应该这样做。嗯，在这个特殊情况下不是这样。它输出True，并且在我测试过的框架的每个版本上都是这样。(不可否认，我还没有在Mono上尝试过……)
只是为了澄清，这只是我正在寻找的事情的一个例子-我并不是特别寻找对这个奇怪现象的讨论/解释。(这和普通的弦乐实习不一样;特别地，当调用构造函数时，字符串实习通常不会发生。)我真的是在要求类似的奇怪行为。
还有其他的宝藏吗?
当前回答
分配!
这是我在聚会上喜欢问的一个问题(这可能是我不再被邀请的原因):
你能编译下面这段代码吗?
public void Foo()
{
this = new Teaser();
}
一个简单的欺骗可以是:
string cheat = @"
public void Foo()
{
this = new Teaser();
}
";
但真正的解决方案是:
public struct Teaser
{
public void Foo()
{
this = new Teaser();
}
}
值类型(结构体)可以重新赋值它们的this变量，这是一个小常识。
其他回答
这是我最近才发现的一个……
interface IFoo
{
string Message {get;}
}
...
IFoo obj = new IFoo("abc");
Console.WriteLine(obj.Message);
乍一看，上述做法很疯狂，但实际上是合法的。不，真的(虽然我错过了一个关键部分，但它不是任何像“添加一个称为IFoo的类”或“添加一个使用别名将IFoo指向一个类”这样的俗套)。
看看你是否能找出原因:谁说你不能实例化一个接口?
我不确定你是否会说这是Windows Vista/7的怪癖或。net的怪癖，但它让我挠头了好一阵子。
string filename = @"c:\program files\my folder\test.txt";
System.IO.File.WriteAllText(filename, "Hello world.");
bool exists = System.IO.File.Exists(filename); // returns true;
string text = System.IO.File.ReadAllText(filename); // Returns "Hello world."
在Windows Vista/7中，文件实际上会被写入C:\Users\<username>\Virtual Store\Program Files\my folder\test.txt
有趣的是，当我第一次看到它时，我认为这是c#编译器正在检查的东西，但即使你直接发出IL来消除任何干扰的机会，它仍然会发生，这意味着它真的是newobj操作代码正在进行检查。
var method = new DynamicMethod("Test", null, null);
var il = method.GetILGenerator();
il.Emit(OpCodes.Ldc_I4_0);
il.Emit(OpCodes.Newarr, typeof(char));
il.Emit(OpCodes.Newobj, typeof(string).GetConstructor(new[] { typeof(char[]) }));
il.Emit(OpCodes.Ldc_I4_0);
il.Emit(OpCodes.Newarr, typeof(char));
il.Emit(OpCodes.Newobj, typeof(string).GetConstructor(new[] { typeof(char[]) }));
il.Emit(OpCodes.Call, typeof(object).GetMethod("ReferenceEquals"));
il.Emit(OpCodes.Box, typeof(bool));
il.Emit(OpCodes.Call, typeof(Console).GetMethod("WriteLine", new[] { typeof(object) }));
il.Emit(OpCodes.Ret);
method.Invoke(null, null);
如果检查string，它也等于true。这意味着这个操作代码必须有特殊的行为来实习空字符串。
我来派对晚了一点，但我有三四五
If you poll InvokeRequired on a control that hasn't been loaded/shown, it will say false - and blow up in your face if you try to change it from another thread (the solution is to reference this.Handle in the creator of the control). Another one which tripped me up is that given an assembly with: enum MyEnum { Red, Blue, } if you calculate MyEnum.Red.ToString() in another assembly, and in between times someone has recompiled your enum to: enum MyEnum { Black, Red, Blue, } at runtime, you will get "Black". I had a shared assembly with some handy constants in. My predecessor had left a load of ugly-looking get-only properties, I thought I'd get rid of the clutter and just use public const. I was more than a little surprised when VS compiled them to their values, and not references. If you implement a new method of an interface from another assembly, but you rebuild referencing the old version of that assembly, you get a TypeLoadException (no implementation of 'NewMethod'), even though you have implemented it (see here). Dictionary<,>: "The order in which the items are returned is undefined". This is horrible, because it can bite you sometimes, but work others, and if you've just blindly assumed that Dictionary is going to play nice ("why shouldn't it? I thought, List does"), you really have to have your nose in it before you finally start to question your assumption.
如果您有一个泛型类，它的方法可以根据类型参数而变得模糊，该怎么办?我最近在写一本双向词典时遇到了这种情况。我想要编写对称的Get()方法，它将返回传递的任何参数的相反值。就像这样:
class TwoWayRelationship<T1, T2>
{
public T2 Get(T1 key) { /* ... */ }
public T1 Get(T2 key) { /* ... */ }
}
如果你创建一个实例，其中T1和T2是不同类型的，那么一切都很好:
var r1 = new TwoWayRelationship<int, string>();
r1.Get(1);
r1.Get("a");
但如果T1和T2是相同的(可能如果一个是另一个的子类)，这是一个编译器错误:
var r2 = new TwoWayRelationship<int, int>();
r2.Get(1); // "The call is ambiguous..."
有趣的是，第二种情况下的所有其他方法仍然可用;只有调用现在模棱两可的方法才会导致编译器错误。有趣的案例，只是有点不太可能和晦涩。
