Why does C# always use callvirt? - followup
I was responding in comments, but it doesn't allow me to use links, so here's the long version:
Judah,
Yes, marking everything as virtual would have little performance impact. It would, however, be a Bad Thing. It's #3 on my list of deadly sins...
ShayEr,
cmp [exc], exc is the solution to the problem. It's there because that's what the JIT generates to do the null test.
Sankar,
Yes, you are missing something. Methods need to be marked as virtual for them to be virtual methods - this is separate from emitting the callvirt instruction.
Allesandro,
I'm not sure I understand your example (why are you calling ToString() on b when b is already a string?). It seems to me that what you want can be handled through a method that tests for null and returns either the result of ToString() or the appropriate default value (String.Empty seems to be the logical one in this case).
Comments
Anonymous
July 07, 2008
PingBack from http://blog.a-foton.ru/2008/07/why-does-c-always-use-callvirt-followup/Anonymous
July 08, 2008
It would be a bad thing, eh? Even though it enables mocking of every instance class you create? Man, I have a hard time swallowing that. Mocking in Java is easier because methods are virtual by default. C# this is tough -- you can't intercept method calls to non-virtual methods, resulting in sometimes painful unit testing, as mock frameworks can't tell if you've called some method.Anonymous
July 08, 2008
Peripherally related to that is how all sorts of useful things in the .NET framework libraries are marked as private or internal so that they can't be used by outside code. I can understand why, of course, but it's still a bit frustrating at times.