It seems that reading a developer's blog is a shortcut to gaining knowledge, especially when the developer is responsible for a product that is one of the infrastructure you use every day, such as saying ... Compiler. When I read Eric Lippert's blog, I accidentally learned a lot about things I didn't know before, such as some language features, some programming ideas, but more interestingly, I learned a lot about the weird parts of the product he was responsible for.
Opening tidbits:
If we now have an enum type E, where one of the enumerated values is named X.
You may know that the expression is right:
C # code
0 | E.x
But you may not know that the expression (according to the language specification) is wrong:
C # code
0 | 0 | E.x
Be curious about this please go to the original view details: The Root of all Evil, part one
The error is that the C # 2.0 specification indicates that "literal 0" can be converted to any enumerated type. Is "literal 0", not "compile-time 0".
This is this ... Aargh, it ' s driving me nuts! (imitating Eric's tone.)
If you put the following code into the. NET Framework 3.5 Beta 2, you will see that the compiler does not give a warning about the second case mentioned above:
C # code
enum E {
x = 1
}
class Program {
public static void Main(string[] args) {
E e = 0 | 0 | E.x;
}
}
The compiler complains that the local variable e has not been used (and potentially means that the variable has no effect, is superfluous), but does not give a warning about the issues we care about here. Just installed the. NET Framework 3.5 RTM, the test results are still the same. Mono 1.2.5.1 's behavior in this regard is consistent with the foregoing.
In the 1.10 enum of Unified C # 3.0 specification, the
Reference
In order for the default value of a enum type to is easily available, the literal 0 implicitly converts to any enum type.
As with the previous versions of the regulations, it is still said that "literal 0" instead of "compile-time 0" can be converted to any enumerated type.
So the. NET framework and Mono are "very helpless" at this point can not be consistent with the specification. =_=||
Anonymous delegate in C # methods of derived classes calling a method of a base class produces unverifiable code
Original: Why are base class calls from anonymous delegates nonverifiable?