I normally program in languages that have the concept of zero-cost abstractions like C++ and Rust.
Currently I'm working in a project that uses C# language. So I was wondering if I can safely create abstractions and higher level code without compromising the performance.
Is that possible in C# or for performance critical code I should just do as low level code as possible?
Just as an example I encountered in my code (don't focus too much on this example, my question is more high level), I needed a function that would return multiple values, for that, my first approach was to use a tuple, so something like this:
public (int, int, float) Function();
or Abstract this tuple into a struct:
public struct Abstraction { int value1; int value2; float value3; };
public Abstraction Function();
What I expected is that the compiler would optimize the Tuple or the Abstraction struct away and simply use the primitive values directly. But what I found is that writing the code using out parameters would improve performance:
public void Function(out int value1, out int value2, out float value3);
I'm guessing the reason is because in the out function, there is no Tuple or Abstraction struct creation.
The problem with the out function version is that I really hate to use parameters as return values, since it seems more like a hack to a language limitation.
So, in the end I'm not sure if I'm just not using the correct configuration so the JIT could use zero-cost abstraction or this is simply not possible or not guaranteed in C#.
First of all, I don't think it makes sense to say that languages "have zero-cost abstractions". Consider the abstraction of function. Is it zero-cost? Generally speaking, it is zero-cost only if it's inlined. And while C++ compilers tend to be really good about inlining functions, they don't inline all functions, so function in C++ is strictly speaking not a zero-cost abstraction. But this difference only matters rarely in practice, which is why you can usually consider a function to be zero-cost.
Now, modern C++ and Rust are designed and implemented in such a way that they make abstractions zero-cost as often as possible. Is this different in C#? Kind of. C# is not designed with such focus on zero-cost abstractions (e.g. invoking a lambda in C# always involves what's effectively a virtual call; invoking a lambda in C++ does not, which makes it much easier to make it zero-cost). Also, JIT compilers generally can't afford to spend as much time on optimizations like inlining and so they generate worse code for abstractions than C++ compilers. (Though this might change in the future, since .Net Core 2.1 introduced a tiered JIT, which means it has more time for optimizations.)
On the other hand, the JIT compiler is tweaked to work well for real code, not for microbenchmarks (which I assume is how you came to the conclusion that returning a struct has worse performance).
In my microbenchmark, using a struct indeed had worse performance, but it was because JIT decided not to inline that version of Function, it was not because of the cost of creating a struct, or anything like that. If I fixed that by using [MethodImpl(MethodImplOptions.AggressiveInlining)], both versions achieved the same performance.
So, returning a struct can be a zero-cost abstraction in C#. Though it's true that there is smaller chance of that happening in C# than in C++.
If you want to know what is the actual effect of switching between out parameters and returning a struct, I suggest you write a more realistic benchmark, not a microbenchmark, and see what the results are. (Assuming I got it right that you used a microbenchmark.)
Yes, you "can"; but is very difficult to control. So, you always had to test and measure.
A practical example with "zero cost abstraction":
using System;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
public class App
{
interface IMessages {
string Welcome{ get; }
string Goodbye { get; }
}
partial struct EnglishMessages : IMessages {
public string Welcome {
get { return "Welcome"; }
}
public string Goodbye {
get { return "Goodbye"; }
}
}
partial struct SpanishMessages : IMessages {
public string Welcome {
get { return "Bienvenido"; }
}
public string Goodbye {
get { return "Adios"; }
}
}
static partial class Messages
{
public static SpanishMessages BuildLang {
get { return default; }
}
}
public static void Main() {
Console.WriteLine(Messages.Welcome);
Console.WriteLine(Messages.Goodbye);
}
static partial class Messages
{
public static string Welcome {
[MethodImpl(MethodImplOptions.AggressiveInlining)]
get { return GetWelcomeFrom(BuildLang); }
}
public static string Goodbye {
[MethodImpl(MethodImplOptions.AggressiveInlining)]
get { return GetGoodbyeFrom(BuildLang); }
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static string GetWelcomeFrom<T>()
where T : struct, IMessages
{
var v = default(T);
return v.Welcome;
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static string GetWelcomeFrom<T>(T _)
where T : struct, IMessages
{
return GetWelcomeFrom<T>();
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static string GetGoodbyeFrom<T>()
where T : struct, IMessages
{
var v = default(T);
return v.Goodbye;
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static string GetGoodbyeFrom<T>(T _)
where T : struct, IMessages
{
return GetGoodbyeFrom<T>();
}
}
#region
[StructLayout(LayoutKind.Explicit, Size = 0)]
partial struct EnglishMessages { [FieldOffset(0)] int _; }
[StructLayout(LayoutKind.Explicit, Size = 0)]
partial struct SpanishMessages { [FieldOffset(0)] int _; }
#endregion
}
You can able to understand the tricks with this code:
using System;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
public class App
{
interface IMessage {
string Value { get; }
bool IsError { get; }
}
static class Messages
{
// AggressiveInlining increase the inline cost threshold,
// decreased by the use of generics.
//
// This allow inlining because has low cost,
// calculated with the used operations.
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static string GetValue<T>()
where T : struct, IMessage
{
// Problem:
// return default(T).Value
//
// Creates a temporal variable using the CIL stack operations.
// Which avoid some optimizers (like coreclr) to eliminate them.
// Solution:
// Create a variable which is eliminated by the optimizer
// because is unnecessary memory.
var v = default(T);
return v.Value;
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static bool IsError<T>()
where T : struct, IMessage
{
var v = default(T);
return v.IsError;
}
}
// The use of partial is only to increase the legibility,
// moving the tricks to the end
partial struct WelcomeMessageEnglish : IMessage {
public string Value {
get { return "Welcome"; }
}
public bool IsError {
get { return false; }
}
}
partial struct WelcomeMessageSpanish : IMessage {
public string Value {
get { return "Bienvenido"; }
}
public bool IsError {
get { return false; }
}
}
public static void Main() {
Console.WriteLine(Messages.GetValue<WelcomeMessageEnglish>() );
Console.WriteLine(Messages.GetValue<WelcomeMessageSpanish>() );
}
// An struct has Size = 1 and is initializated to 0
// This avoid that, setting Size = 0
#region
[StructLayout(LayoutKind.Explicit, Size = 0)]
partial struct WelcomeMessageEnglish { [FieldOffset(0)] int _; }
[StructLayout(LayoutKind.Explicit, Size = 0)]
partial struct WelcomeMessageSpanish { [FieldOffset(0)] int _; }
#endregion
}
I "tested" this in CoreClr, Roslyn, Mono and the abstraction has "zero cost":
App.Main()
L0000: push ebp
L0001: mov ebp, esp
L0003: mov ecx, [0xfd175c4]
L0009: call System.Console.WriteLine(System.String)
L000e: mov ecx, [0xfd17628]
L0014: call System.Console.WriteLine(System.String)
L0019: pop ebp
L001a: ret
For coreclr and roslyn, you can view the asm in SharpLab: Here.
And for mono (in GNU/Linux):
mono --aot zerocost.exe
objdump -d -M intel zerocost.exe.so > zerocost.exe.so.dump
cat zerocost.exe.so.dump #Looking for <App_Main>
When you return something, you always create a new object – you save that step completely when just working "in place" with your out parameters.
Then, you have things that your compiler can't simply optimize away – I'd have to tell you a bit about strict aliasing rules in C, but I don't know C# enough to know whether similar things apply here.
So, in general, creating an object of tuple or Abstraction type is not optimizable away. You specifically specified you wanted to return an object of that type, so that object has to be created by a "general" compilation of the function. You could argue that the compiler knows the context in which Function is called and could infer that it's OK to not generate the object but directly work as if these were reference to the things that you assign the fields of Abstraction to later, but here aliasing rules might get really complicated, and that will in general be logically impossible to do.
My app uses several "handles" (all IntPtr's) of varying "type".
I want to help ensure that the correct handle type are passed to my various methods... if I used IntPtr for them all then there's no hint that the method takes handle type A or handle type B.
If L were in C++ land I could use typedefs:
typedef uint32 HdlA;
typedef uint32 HdlB;
and now I have two types, HdlA and HdlB, both of which are generic U32's under the hood.
In C++ I could also use a macro to declare the structs.
Additionally, for marshaling reasons, I need these to be value types... can't use a class (naturally, if I could use class that would solve everything).
All handles have essentially identical definitions:
public struct HdlA
{
private IntPtr _h;
public bool IsValid get { return (_h != IntPtr.Zero);} }
//public HdlA() { _h = IntPtr.Zero; } // C# disallows arg-less ctor on struct
public HdlA(IntPtr h) { _h = h; }
public void Invalidate() { _h = IntPtr.Zero; }
public static implicit operator IntPtr(HdlA hdl) { return hdl._h; }
}
public struct HdlB
{
private IntPtr _h;
public bool IsValid get { return (_h != IntPtr.Zero);} }
//public HdlB() { _h = IntPtr.Zero; } // C# disallows arg-less ctor on struct
public HdlB(IntPtr h) { _h = h; }
public void Invalidate() { _h = IntPtr.Zero; }
public static implicit operator IntPtr(HdlB hdl) { return hdl._h; }
}
... etc ...
I certainly can do this longhand - I can declare 5 or 6 identical blocks of code where only the struct names vary - but that's not very elegant.
I've considered using an Interface, but that disallows member fields, so no luck there.
What I'd love is to have a base struct then have HdlA, HdlB, etc simply derive off the base. But C# disallows base types in structs.
This seems like something that should have an easy and elegant solution, but it's escaping me :(
Any ideas?
One solution is to use only one struct with all common fields and add a field(int or Enum) that shows the type of the struct you want to use. Of course if you were able to use classes you would have used Inheritance but in this scenario adding a HandleType field may solve the problem.
You can then check that field in each method to see the right struct has been passed or not.
You don't provide a great deal of context in your question, so I'm stabbing wildly in the dark here.
It might be possible to use classes in your situation, after all. Declare the abstract base class, derive HndlA and HndlB from it, and provide a ToHandle() method on the base class that converts the class to a struct. The value from ToHandle() would be the object you marshal.
Again, just stabbing wildly in the dark.
In C++ I could also use a macro to declare the structs.
In C# you can use a T4 template.
Or strictly, it's not C# itself, though it can use C# as both the script language, and the output, and it can be part of the build in pretty much any build tool for C# (VisualStudio, MonoDevelop, SharpDevelop, Nant) other than just calling the compiler itself.
Create a file with a .tt or .t4 extension like:
<## template language="C#" #>
<## output extension=".generated.cs" #>
namespace SomeNamespace
{
<#
foreach(string name in new string[]{"HdlA", "HdlB", /*… and so on… */})
{#>
public struct <#=name#>
{
private IntPtr _h;
public bool IsValid
{
get { return (_h != IntPtr.Zero); }
}
public <#=name#>(IntPtr h)
{
_h = h;
}
public void Invalidate()
{
_h = IntPtr.Zero;
}
public static implicit operator IntPtr(<#=name#> hdl)
{
return hdl._h;
}
}
<#}#>
}
It works pretty much as ASP.NET does, but produces a local file. Here we use it to produce a .cs file that will then be part of the compilation, rebuilding the .cs file first if necessary. Alas, while it's a generated file, it causes problems if you don't include it in your source control (must start a question on that irritation).
Here is a real example of mine that's a bit more realistic. Here rather than wanting similar classes with different names, I wanted different methods with different types, but it's the same basic principle.
By the way,
// C# disallows arg-less ctor on struct
Depending on how you look at it, you could also say that it insists that you must have a predefined arg-less zero-filling constructor, that you can't get rid of or replace (there's [usually] no such method, but we do use new blah() in the calling C#). While it's possible in .NET to do otherwise, the differences in the cases where it is called or where zero-filling happens cause enough confusion that insisting that the constructor match zero-filling does save some problems.
Broken code
public static partial class LogicExtensions {
public static bool Implies<T>(this T premise, T conclusion) {
return conclusion.Infers(premise);
}
public static bool Infers<T>(this T premise, T conclusion) {
return premise.Implies(conclusion);
}
}
The code above is expecting to express:
The conclusion infers the premise because of the premise implies the conclusion.
The the premise implies the conclusion because of the conclusion infers the premise.
It would be circular reasoning, and definitely will cause stack overflow. I then redesign it as follows:
Working code
public delegate bool Paradox<T>(T premise, T conclusion, Paradox<T> predicate=null);
public static partial class LogicExtensions {
public static bool Implies<T>(this T premise, T conclusion, Paradox<T> predicate=null) {
if(null==predicate)
return conclusion.Infers(premise, Implies);
if(Infers!=predicate)
return predicate(premise, conclusion);
return LogicExtensions.Implies(conclusion as IConvertible, premise as IConvertible);
}
public static bool Infers<T>(this T premise, T conclusion, Paradox<T> predicate=null) {
if(null==predicate)
return premise.Implies(conclusion, Infers);
if(Implies!=predicate)
return predicate(premise, conclusion);
return LogicExtensions.Implies(conclusion as IConvertible, premise as IConvertible);
}
static bool Implies<T>(T premise, T conclusion) where T: IConvertible {
var x=premise.ToUInt64(null);
return x==(x&conclusion.ToUInt64(null));
}
}
But that means:
It fails on the correct logic that it cannot go without Paradox<T> which I initially named Predicate<T> but is conflict with System.Predicate<T>.
It's defective that T must implement IConvertable unlike the code former.
To be clear, I'm trying to make the code not only works but also represent like logical formulas that I can further reuse it to reason about logic without a constraint of T implements IConvertable. Is there a way make the logic correct and get rid of the defective design?
It is not very clear from your question what are you trying to do. Are you trying to express some logical predicates in C#? Are you trying to write code that will reason about logic? Are you trying to represent logical formulas?
Paradoxes. When talking about paradoxes in computations, it might be good to read about lambda calculus and Russel's paradox (here is a nice article). Lambda calculus is essentially a simple functional programming language (imagine C# with lambda functions and application, but nothing else).
It was first developed as a system for the foundation of mathematics (before computers were invented), but this did not really work because you were able to write recursive computations that did not make sense (see the article for details), but you can write a computation that evaluates as follows (in C# notation):
r(r) = not(r(r)) = not(not(r(r)))
... and since there is no x = r(r) such that x = not(x), the model does not make sense as foundation of mathematics. But it is useful as a model of programming languages where you can write recursive computations - though they may never terminate.
Representing logic. If you want to represent logical formulas in your program, then you probably want to separate the representation of formula from the reasoning. This is best done in functional languages (like F#), but you can do it in C# too (just with more typing). The F# representation of a formula would be something like:
type Formula =
| Variable of string
| Negation of Formula
| Implies of Formula * Formula
The idea is that a formula is either a variable (named) or a negation of another formula or an implication where one formula implies another. In C#, you can represent the same thing as a class hierarchy (with Formula as a base class and three derived classes.)
Your reasoning can then be implemented as a method that manipulates formulas. In F#, this can be done quite easily using pattern matching. In C#, you'll probably need to use type tests to write code that checks if the argument is Variable (then do something...); if the argument is Negation (then do something...) etc.
Dropping IConvertible
Let's start with the 'easy part': dropping the IConvertible. The reason you need it is because you want this code to work on all types, which means you cannot always influence that it has a certain member (Implies). What you would like to do is what they call in C++: template specialization, but unfortunately isn't available (yet?) in C#:
static bool Implies<T>(T premise, T conclusion) where T : IConvertible
{
var x = premise.ToUInt64(null);
return x == (x & conclusion.ToUInt64(null));
}
static bool Implies<T>(T premise, T conclusion) where T : Foobar
{
// other fancy logic
}
// and so on
The easiest way to solve this is by using multimethods. You can use the 'dynamic' keyword for this:
public partial class Implications
{
internal static bool CheckImplies<T>(T lhs, T rhs)
{
return Implies((dynamic)lhs, (dynamic)rhs);
}
public static bool Implies(int lhs, int rhs)
{
return lhs == (lhs & rhs);
}
// your other implies thingies implement this same partial class
}
public static partial class LogicExtensions
{
public static bool Implies<T>(this T premise, T conclusion, Paradox<T> predicate = null)
{
if (null == predicate)
return conclusion.Infers(premise, Implies);
if (Infers != predicate)
return predicate(premise, conclusion);
return Implications.CheckImplies(premise, conclusion);
}
public static bool Infers<T>(this T premise, T conclusion, Paradox<T> predicate = null)
{
if (null == predicate)
return premise.Implies(conclusion, Infers);
if (Implies != predicate)
return predicate(premise, conclusion);
return Implications.CheckImplies(premise, conclusion);
}
}
And if you have a 'third' method, you can simply call it
I've been looking a couple of minutes at the strange recursive definition and it doesn't really make sense to me... if you have a third helper method anyways, why not simply call it directly? :-)
public static bool Implies<T>(this T premise, T conclusion)
{
return Implications.CheckImplies(premise, conclusion);
}
public static bool Infers<T>(this T premise, T conclusion)
{
return Implications.CheckImplies(conclusion, premise);
}
The not(not(T)) problem
While the above didn't make much sense to me, I find it perfectly reasonable to use the type system and the language to help you out a bit. Well, surely you can do that and this is how I would do that... :-)
Let's introduce a 'Not' class with a generic:
public class Not<T>
{
public Not(T val)
{
this.not = val;
}
internal T not;
}
If we have a Not> situation here, we want to give - otherwise, we want to use directly. Well, we can do that quite easy with some extensions:
public static T Optimize<T>(this Not<Not<T>> var)
{
return Optimize(var.not.not);
}
public static T Optimize<T>(this T var)
{
return var;
}
To test it, you can do a similar thing:
var val = new Not<Not<int>>(new Not<int>(2));
var result = val.Optimize();
This works, because overload resolution will pick the correct Optimize call, which ensures you will optimize the Not>>>> into the T value and so on.
It also works, because we wrap the 'Not' in a wrapper class and then use the type system to our advantage.
Going back to the original problem
Instead of directly evaluating 'Implies' and 'Infers', why not use a temporary object to do your evil work. You can use operator overloading (implicit conversion to be precise) to specify how Implies and Infers relate. The only catch is that it has its limits with extension methods.
C# operator overloading will then pick the best matching method. In the first case this will be the exact match, in the second case, the method will be implicitly converted and afterwards Evaluate will be called. In other words, it will not stack overflow, simply because it will do its evaluation lazy. Ready for the code? :-)
public class Implies<T>
{
public Implies(T premise, T conclusion)
{
this.premise = premise;
this.conclusion = conclusion;
}
public T premise;
public T conclusion;
public static implicit operator Infers<T>(Implies<T> src)
{
return new Infers<T>(src.conclusion, src.premise);
}
}
public class Infers<T>
{
public Infers(T premise, T conclusion)
{
this.premise = premise;
this.conclusion = conclusion;
}
public T premise;
public T conclusion;
public static implicit operator Implies<T>(Infers<T> src)
{
return new Implies<T>(src.conclusion, src.premise);
}
}
public static partial class LogicExtensions
{
public static Implies<T> Implies<T>(this T premise, T conclusion)
{
return new Implies<T>(premise, conclusion);
}
public static Infers<T> Infers<T>(this T premise, T conclusion)
{
return new Infers<T>(premise, conclusion);
}
}
public class Foo
{
// The things you wish to implement :-)
public static bool Evaluate(Implies<int> impl)
{
return impl.premise == (impl.conclusion & impl.premise);
}
static void Main(string[] args)
{
Implies<int> impl= 0.Implies(2); // will be called directly
Infers<int> impl2 = 0.Infers(2); // will be converted
Console.WriteLine("Res: {0} {1}", Evaluate(impl), Evaluate(impl2));
Console.ReadLine();
}
}
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I collect a few corner cases and brain teasers and would always like to hear more. The page only really covers C# language bits and bobs, but I also find core .NET things interesting too. For example, here's one which isn't on the page, but which I find incredible:
string x = new string(new char[0]);
string y = new string(new char[0]);
Console.WriteLine(object.ReferenceEquals(x, y));
I'd expect that to print False - after all, "new" (with a reference type) always creates a new object, doesn't it? The specs for both C# and the CLI indicate that it should. Well, not in this particular case. It prints True, and has done on every version of the framework I've tested it with. (I haven't tried it on Mono, admittedly...)
Just to be clear, this is only an example of the kind of thing I'm looking for - I wasn't particularly looking for discussion/explanation of this oddity. (It's not the same as normal string interning; in particular, string interning doesn't normally happen when a constructor is called.) I was really asking for similar odd behaviour.
Any other gems lurking out there?
I think I showed you this one before, but I like the fun here - this took some debugging to track down! (the original code was obviously more complex and subtle...)
static void Foo<T>() where T : new()
{
T t = new T();
Console.WriteLine(t.ToString()); // works fine
Console.WriteLine(t.GetHashCode()); // works fine
Console.WriteLine(t.Equals(t)); // works fine
// so it looks like an object and smells like an object...
// but this throws a NullReferenceException...
Console.WriteLine(t.GetType());
}
So what was T...
Answer: any Nullable<T> - such as int?. All the methods are overridden, except GetType() which can't be; so it is cast (boxed) to object (and hence to null) to call object.GetType()... which calls on null ;-p
Update: the plot thickens... Ayende Rahien threw down a similar challenge on his blog, but with a where T : class, new():
private static void Main() {
CanThisHappen<MyFunnyType>();
}
public static void CanThisHappen<T>() where T : class, new() {
var instance = new T(); // new() on a ref-type; should be non-null, then
Debug.Assert(instance != null, "How did we break the CLR?");
}
But it can be defeated! Using the same indirection used by things like remoting; warning - the following is pure evil:
class MyFunnyProxyAttribute : ProxyAttribute {
public override MarshalByRefObject CreateInstance(Type serverType) {
return null;
}
}
[MyFunnyProxy]
class MyFunnyType : ContextBoundObject { }
With this in place, the new() call is redirected to the proxy (MyFunnyProxyAttribute), which returns null. Now go and wash your eyes!
Bankers' Rounding.
This one is not so much a compiler bug or malfunction, but certainly a strange corner case...
The .Net Framework employs a scheme or rounding known as Banker's Rounding.
In Bankers' Rounding the 0.5 numbers are rounded to the nearest even number, so
Math.Round(-0.5) == 0
Math.Round(0.5) == 0
Math.Round(1.5) == 2
Math.Round(2.5) == 2
etc...
This can lead to some unexpected bugs in financial calculations based on the more well known Round-Half-Up rounding.
This is also true of Visual Basic.
What will this function do if called as Rec(0) (not under the debugger)?
static void Rec(int i)
{
Console.WriteLine(i);
if (i < int.MaxValue)
{
Rec(i + 1);
}
}
Answer:
On 32-bit JIT it should result in a StackOverflowException
On 64-bit JIT it should print all the numbers to int.MaxValue
This is because the 64-bit JIT compiler applies tail call optimisation, whereas the 32-bit JIT does not.
Unfortunately I haven't got a 64-bit machine to hand to verify this, but the method does meet all the conditions for tail-call optimisation. If anybody does have one I'd be interested to see if it's true.
Assign This!
This is one that I like to ask at parties (which is probably why I don't get invited anymore):
Can you make the following piece of code compile?
public void Foo()
{
this = new Teaser();
}
An easy cheat could be:
string cheat = #"
public void Foo()
{
this = new Teaser();
}
";
But the real solution is this:
public struct Teaser
{
public void Foo()
{
this = new Teaser();
}
}
So it's a little know fact that value types (structs) can reassign their this variable.
Few years ago, when working on loyality program, we had an issue with the amount of points given to customers. The issue was related to casting/converting double to int.
In code below:
double d = 13.6;
int i1 = Convert.ToInt32(d);
int i2 = (int)d;
does i1 == i2 ?
It turns out that i1 != i2.
Because of different rounding policies in Convert and cast operator the actual values are:
i1 == 14
i2 == 13
It's always better to call Math.Ceiling() or Math.Floor() (or Math.Round with MidpointRounding that meets our requirements)
int i1 = Convert.ToInt32( Math.Ceiling(d) );
int i2 = (int) Math.Ceiling(d);
They should have made 0 an integer even when there's an enum function overload.
I knew C# core team rationale for mapping 0 to enum, but still, it is not as orthogonal as it should be. Example from Npgsql.
Test example:
namespace Craft
{
enum Symbol { Alpha = 1, Beta = 2, Gamma = 3, Delta = 4 };
class Mate
{
static void Main(string[] args)
{
JustTest(Symbol.Alpha); // enum
JustTest(0); // why enum
JustTest((int)0); // why still enum
int i = 0;
JustTest(Convert.ToInt32(0)); // have to use Convert.ToInt32 to convince the compiler to make the call site use the object version
JustTest(i); // it's ok from down here and below
JustTest(1);
JustTest("string");
JustTest(Guid.NewGuid());
JustTest(new DataTable());
Console.ReadLine();
}
static void JustTest(Symbol a)
{
Console.WriteLine("Enum");
}
static void JustTest(object o)
{
Console.WriteLine("Object");
}
}
}
This is one of the most unusual i've seen so far (aside from the ones here of course!):
public class Turtle<T> where T : Turtle<T>
{
}
It lets you declare it but has no real use, since it will always ask you to wrap whatever class you stuff in the center with another Turtle.
[joke] I guess it's turtles all the way down... [/joke]
Here's one I only found out about recently...
interface IFoo
{
string Message {get;}
}
...
IFoo obj = new IFoo("abc");
Console.WriteLine(obj.Message);
The above looks crazy at first glance, but is actually legal.No, really (although I've missed out a key part, but it isn't anything hacky like "add a class called IFoo" or "add a using alias to point IFoo at a class").
See if you can figure out why, then: Who says you can’t instantiate an interface?
When is a Boolean neither True nor False?
Bill discovered that you can hack a boolean so that if A is True and B is True, (A and B) is False.
Hacked Booleans
I'm arriving a bit late to the party, but I've got three four five:
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.
VB.NET, nullables and the ternary operator:
Dim i As Integer? = If(True, Nothing, 5)
This took me some time to debug, since I expected i to contain Nothing.
What does i really contain? 0.
This is surprising but actually "correct" behavior: Nothing in VB.NET is not exactly the same as null in CLR: Nothing can either mean null or default(T) for a value type T, depending on the context. In the above case, If infers Integer as the common type of Nothing and 5, so, in this case, Nothing means 0.
I found a second really strange corner case that beats my first one by a long shot.
String.Equals Method (String, String, StringComparison) is not actually side effect free.
I was working on a block of code that had this on a line by itself at the top of some function:
stringvariable1.Equals(stringvariable2, StringComparison.InvariantCultureIgnoreCase);
Removing that line lead to a stack overflow somewhere else in the program.
The code turned out to be installing a handler for what was in essence a BeforeAssemblyLoad event and trying to do
if (assemblyfilename.EndsWith("someparticular.dll", StringComparison.InvariantCultureIgnoreCase))
{
assemblyfilename = "someparticular_modified.dll";
}
By now I shouldn't have to tell you. Using a culture that hasn't been used before in a string comparison causes an assembly load. InvariantCulture is not an exception to this.
Here is an example of how you can create a struct that causes the error message "Attempted to read or write protected memory. This is often an indication that other memory is corrupt".
The difference between success and failure is very subtle.
The following unit test demonstrates the problem.
See if you can work out what went wrong.
[Test]
public void Test()
{
var bar = new MyClass
{
Foo = 500
};
bar.Foo += 500;
Assert.That(bar.Foo.Value.Amount, Is.EqualTo(1000));
}
private class MyClass
{
public MyStruct? Foo { get; set; }
}
private struct MyStruct
{
public decimal Amount { get; private set; }
public MyStruct(decimal amount) : this()
{
Amount = amount;
}
public static MyStruct operator +(MyStruct x, MyStruct y)
{
return new MyStruct(x.Amount + y.Amount);
}
public static MyStruct operator +(MyStruct x, decimal y)
{
return new MyStruct(x.Amount + y);
}
public static implicit operator MyStruct(int value)
{
return new MyStruct(value);
}
public static implicit operator MyStruct(decimal value)
{
return new MyStruct(value);
}
}
C# supports conversions between arrays and lists as long as the arrays are not multidimensional and there is an inheritance relation between the types and the types are reference types
object[] oArray = new string[] { "one", "two", "three" };
string[] sArray = (string[])oArray;
// Also works for IList (and IEnumerable, ICollection)
IList<string> sList = (IList<string>)oArray;
IList<object> oList = new string[] { "one", "two", "three" };
Note that this does not work:
object[] oArray2 = new int[] { 1, 2, 3 }; // Error: Cannot implicitly convert type 'int[]' to 'object[]'
int[] iArray = (int[])oArray2; // Error: Cannot convert type 'object[]' to 'int[]'
This is the strangest I've encountered by accident:
public class DummyObject
{
public override string ToString()
{
return null;
}
}
Used as follows:
DummyObject obj = new DummyObject();
Console.WriteLine("The text: " + obj.GetType() + " is " + obj);
Will throw a NullReferenceException. Turns out the multiple additions are compiled by the C# compiler to a call to String.Concat(object[]). Prior to .NET 4, there is a bug in just that overload of Concat where the object is checked for null, but not the result of ToString():
object obj2 = args[i];
string text = (obj2 != null) ? obj2.ToString() : string.Empty;
// if obj2 is non-null, but obj2.ToString() returns null, then text==null
int length = text.Length;
This is a bug by ECMA-334 §14.7.4:
The binary + operator performs string concatenation when one or both operands are of type string. If an operand of string concatenation is null, an empty string is substituted. Otherwise, any non-string operand is converted to its string representation by invoking the virtual ToString method inherited from type object. If ToString returns null, an empty string is substituted.
Interesting - when I first looked at that I assumed it was something the C# compiler was checking for, but even if you emit the IL directly to remove any chance of interference it still happens, which means it really is the newobj op-code that's doing the checking.
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);
It also equates to true if you check against string.Empty which means this op-code must have special behaviour to intern empty strings.
Public Class Item
Public ID As Guid
Public Text As String
Public Sub New(ByVal id As Guid, ByVal name As String)
Me.ID = id
Me.Text = name
End Sub
End Class
Public Sub Load(sender As Object, e As EventArgs) Handles Me.Load
Dim box As New ComboBox
Me.Controls.Add(box) 'Sorry I forgot this line the first time.'
Dim h As IntPtr = box.Handle 'Im not sure you need this but you might.'
Try
box.Items.Add(New Item(Guid.Empty, Nothing))
Catch ex As Exception
MsgBox(ex.ToString())
End Try
End Sub
The output is "Attempted to read protected memory. This is an indication that other memory is corrupt."
PropertyInfo.SetValue() can assign ints to enums, ints to nullable ints, enums to nullable enums, but not ints to nullable enums.
enumProperty.SetValue(obj, 1, null); //works
nullableIntProperty.SetValue(obj, 1, null); //works
nullableEnumProperty.SetValue(obj, MyEnum.Foo, null); //works
nullableEnumProperty.SetValue(obj, 1, null); // throws an exception !!!
Full description here
What if you have a generic class that has methods that could be made ambiguous depending on the type arguments? I ran into this situation recently writing a two-way dictionary. I wanted to write symmetric Get() methods that would return the opposite of whatever argument was passed. Something like this:
class TwoWayRelationship<T1, T2>
{
public T2 Get(T1 key) { /* ... */ }
public T1 Get(T2 key) { /* ... */ }
}
All is well good if you make an instance where T1 and T2 are different types:
var r1 = new TwoWayRelationship<int, string>();
r1.Get(1);
r1.Get("a");
But if T1 and T2 are the same (and probably if one was a subclass of another), it's a compiler error:
var r2 = new TwoWayRelationship<int, int>();
r2.Get(1); // "The call is ambiguous..."
Interestingly, all other methods in the second case are still usable; it's only calls to the now-ambiguous method that causes a compiler error. Interesting case, if a little unlikely and obscure.
C# Accessibility Puzzler
The following derived class is accessing a private field from its base class, and the compiler silently looks to the other side:
public class Derived : Base
{
public int BrokenAccess()
{
return base.m_basePrivateField;
}
}
The field is indeed private:
private int m_basePrivateField = 0;
Care to guess how we can make such code compile?
.
.
.
.
.
.
.
Answer
The trick is to declare Derived as an inner class of Base:
public class Base
{
private int m_basePrivateField = 0;
public class Derived : Base
{
public int BrokenAccess()
{
return base.m_basePrivateField;
}
}
}
Inner classes are given full access to the outer class members. In this case the inner class also happens to derive from the outer class. This allows us to "break" the encapsulation of private members.
Just found a nice little thing today:
public class Base
{
public virtual void Initialize(dynamic stuff) {
//...
}
}
public class Derived:Base
{
public override void Initialize(dynamic stuff) {
base.Initialize(stuff);
//...
}
}
This throws compile error.
The call to method 'Initialize' needs to be dynamically dispatched, but cannot be because it is part of a base access expression. Consider casting the dynamic arguments or eliminating the base access.
If I write base.Initialize(stuff as object); it works perfectly, however this seems to be a "magic word" here, since it does exactly the same, everything is still recieved as dynamic...
In an API we're using, methods that return a domain object might return a special "null object". In the implementation of this, the comparison operator and the Equals() method are overridden to return true if it is compared with null.
So a user of this API might have some code like this:
return test != null ? test : GetDefault();
or perhaps a bit more verbose, like this:
if (test == null)
return GetDefault();
return test;
where GetDefault() is a method returning some default value that we want to use instead of null. The surprise hit me when I was using ReSharper and following it's recommendation to rewrite either of this to the following:
return test ?? GetDefault();
If the test object is a null object returned from the API instead of a proper null, the behavior of the code has now changed, as the null coalescing operator actually checks for null, not running operator= or Equals().
Consider this weird case:
public interface MyInterface {
void Method();
}
public class Base {
public void Method() { }
}
public class Derived : Base, MyInterface { }
If Base and Derived are declared in the same assembly, the compiler will make Base::Method virtual and sealed (in the CIL), even though Base doesn't implement the interface.
If Base and Derived are in different assemblies, when compiling the Derived assembly, the compiler won't change the other assembly, so it will introduce a member in Derived that will be an explicit implementation for MyInterface::Method that will just delegate the call to Base::Method.
The compiler has to do this in order to support polymorphic dispatch with regards to the interface, i.e. it has to make that method virtual.
The following might be general knowledge I was just simply lacking, but eh. Some time ago, we had a bug case which included virtual properties. Abstracting the context a bit, consider the following code, and apply breakpoint to specified area :
class Program
{
static void Main(string[] args)
{
Derived d = new Derived();
d.Property = "AWESOME";
}
}
class Base
{
string _baseProp;
public virtual string Property
{
get
{
return "BASE_" + _baseProp;
}
set
{
_baseProp = value;
//do work with the base property which might
//not be exposed to derived types
//here
Console.Out.WriteLine("_baseProp is BASE_" + value.ToString());
}
}
}
class Derived : Base
{
string _prop;
public override string Property
{
get { return _prop; }
set
{
_prop = value;
base.Property = value;
} //<- put a breakpoint here then mouse over BaseProperty,
// and then mouse over the base.Property call inside it.
}
public string BaseProperty { get { return base.Property; } private set { } }
}
While in the Derived object context, you can get the same behavior when adding base.Property as a watch, or typing base.Property into the quickwatch.
Took me some time to realize what was going on. In the end I was enlightened by the Quickwatch. When going into the Quickwatch and exploring the Derived object d (or from the object's context, this) and selecting the field base, the edit field on top of the Quickwatch displays the following cast:
((TestProject1.Base)(d))
Which means that if base is replaced as such, the call would be
public string BaseProperty { get { return ((TestProject1.Base)(d)).Property; } private set { } }
for the Watches, Quickwatch and the debugging mouse-over tooltips, and it would then make sense for it to display "AWESOME" instead of "BASE_AWESOME" when considering polymorphism. I'm still unsure why it would transform it into a cast, one hypothesis is that call might not be available from those modules' context, and only callvirt.
Anyhow, that obviously doesn't alter anything in terms of functionality, Derived.BaseProperty will still really return "BASE_AWESOME", and thus this was not the root of our bug at work, simply a confusing component. I did however find it interesting how it could mislead developpers which would be unaware of that fact during their debug sessions, specially if Base is not exposed in your project but rather referenced as a 3rd party DLL, resulting in Devs just saying :
"Oi, wait..what ? omg that DLL is
like, ..doing something funny"
This one's pretty hard to top. I ran into it while I was trying to build a RealProxy implementation that truly supports Begin/EndInvoke (thanks MS for making this impossible to do without horrible hacks). This example is basically a bug in the CLR, the unmanaged code path for BeginInvoke doesn't validate that the return message from RealProxy.PrivateInvoke (and my Invoke override) is returning an instance of an IAsyncResult. Once it's returned, the CLR gets incredibly confused and loses any idea of whats going on, as demonstrated by the tests at the bottom.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.Remoting.Proxies;
using System.Reflection;
using System.Runtime.Remoting.Messaging;
namespace BrokenProxy
{
class NotAnIAsyncResult
{
public string SomeProperty { get; set; }
}
class BrokenProxy : RealProxy
{
private void HackFlags()
{
var flagsField = typeof(RealProxy).GetField("_flags", BindingFlags.NonPublic | BindingFlags.Instance);
int val = (int)flagsField.GetValue(this);
val |= 1; // 1 = RemotingProxy, check out System.Runtime.Remoting.Proxies.RealProxyFlags
flagsField.SetValue(this, val);
}
public BrokenProxy(Type t)
: base(t)
{
HackFlags();
}
public override IMessage Invoke(IMessage msg)
{
var naiar = new NotAnIAsyncResult();
naiar.SomeProperty = "o noes";
return new ReturnMessage(naiar, null, 0, null, (IMethodCallMessage)msg);
}
}
interface IRandomInterface
{
int DoSomething();
}
class Program
{
static void Main(string[] args)
{
BrokenProxy bp = new BrokenProxy(typeof(IRandomInterface));
var instance = (IRandomInterface)bp.GetTransparentProxy();
Func<int> doSomethingDelegate = instance.DoSomething;
IAsyncResult notAnIAsyncResult = doSomethingDelegate.BeginInvoke(null, null);
var interfaces = notAnIAsyncResult.GetType().GetInterfaces();
Console.WriteLine(!interfaces.Any() ? "No interfaces on notAnIAsyncResult" : "Interfaces");
Console.WriteLine(notAnIAsyncResult is IAsyncResult); // Should be false, is it?!
Console.WriteLine(((NotAnIAsyncResult)notAnIAsyncResult).SomeProperty);
Console.WriteLine(((IAsyncResult)notAnIAsyncResult).IsCompleted); // No way this works.
}
}
}
Output:
No interfaces on notAnIAsyncResult
True
o noes
Unhandled Exception: System.EntryPointNotFoundException: Entry point was not found.
at System.IAsyncResult.get_IsCompleted()
at BrokenProxy.Program.Main(String[] args)
I'm not sure if you'd say this is a Windows Vista/7 oddity or a .Net oddity but it had me scratching my head for a while.
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."
In Windows Vista/7 the file will actually be written to C:\Users\<username>\Virtual Store\Program Files\my folder\test.txt
Have you ever thought the C# compiler could generate invalid CIL? Run this and you'll get a TypeLoadException:
interface I<T> {
T M(T p);
}
abstract class A<T> : I<T> {
public abstract T M(T p);
}
abstract class B<T> : A<T>, I<int> {
public override T M(T p) { return p; }
public int M(int p) { return p * 2; }
}
class C : B<int> { }
class Program {
static void Main(string[] args) {
Console.WriteLine(new C().M(42));
}
}
I don't know how it fares in the C# 4.0 compiler though.
EDIT: this is the output from my system:
C:\Temp>type Program.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication1 {
interface I<T> {
T M(T p);
}
abstract class A<T> : I<T> {
public abstract T M(T p);
}
abstract class B<T> : A<T>, I<int> {
public override T M(T p) { return p; }
public int M(int p) { return p * 2; }
}
class C : B<int> { }
class Program {
static void Main(string[] args) {
Console.WriteLine(new C().M(11));
}
}
}
C:\Temp>csc Program.cs
Microsoft (R) Visual C# 2008 Compiler version 3.5.30729.1
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.
C:\Temp>Program
Unhandled Exception: System.TypeLoadException: Could not load type 'ConsoleAppli
cation1.C' from assembly 'Program, Version=0.0.0.0, Culture=neutral, PublicKeyTo
ken=null'.
at ConsoleApplication1.Program.Main(String[] args)
C:\Temp>peverify Program.exe
Microsoft (R) .NET Framework PE Verifier. Version 3.5.30729.1
Copyright (c) Microsoft Corporation. All rights reserved.
[token 0x02000005] Type load failed.
[IL]: Error: [C:\Temp\Program.exe : ConsoleApplication1.Program::Main][offset 0x
00000001] Unable to resolve token.
2 Error(s) Verifying Program.exe
C:\Temp>ver
Microsoft Windows XP [Version 5.1.2600]
There is something really exciting about C#, the way it handles closures.
Instead of copying the stack variable values to the closure free variable, it does that preprocessor magic wrapping all occurences of the variable into an object and thus moves it out of stack - straight to the heap! :)
I guess, that makes C# even more functionally-complete (or lambda-complete huh)) language than ML itself (which uses stack value copying AFAIK). F# has that feature too, as C# does.
That does bring much delight to me, thank you MS guys!
It's not an oddity or corner case though... but something really unexpected from a stack-based VM language :)
From a question I asked not long ago:
Conditional operator cannot cast implicitly?
Given:
Bool aBoolValue;
Where aBoolValue is assigned either True or False;
The following will not compile:
Byte aByteValue = aBoolValue ? 1 : 0;
But this would:
Int anIntValue = aBoolValue ? 1 : 0;
The answer provided is pretty good too.
The scoping in c# is truly bizarre at times. Lets me give you one example:
if (true)
{
OleDbCommand command = SQLServer.CreateCommand();
}
OleDbCommand command = SQLServer.CreateCommand();
This fails to compile, because command is redeclared? There are some interested guesswork as to why it works that way in this thread on stackoverflow and in my blog.