boxing

Possible Duplicate: Structs, Interfaces and Boxing From the MSDN: http://msdn.microsoft.com/en-us/library/yz2be5wk.aspx Boxing is the process of converting a value type to the type object or to any interface type implemented by this value type. But what about generic interfaces? For example, int derives from both IComparable and IComparable<int> . Let's say I have the following code: void foo(IComparable value) { /* etc. */ } void bar(IComparable<T> value) { /* etc. */ } void gizmo() { int i = 42; bar(i); // is `i` boxed? I'd say YES foo(i); // is `i` boxed? I fear it is (but I hope for NO) }

I have a piece of code which I need to understand: public static void main(String[] args) { Character c = new Character('a'); Character cy = new Character('a'); char cx = 'a'; System.out.println(c == cx); System.out.println(cx == cy); System.out.println(c == cy); } Output: true true false I am unable to understand why only the third statement is failing. EDIT: This question is different to the .equals vs == question as this about primitive versus object comparison. c and cy refer to different instances of the Character class (each time you invoke a constructor, you create a new instance), so

My question is somewhat related to this one: How does a generic constraint prevent boxing of a value type with an implicitly implemented interface? , but different because it shouldn't need a constraint to do this because it's not generic at all. I have the code interface I { void F(); } struct C : I { void I.F() {} } static class P { static void Main() { C x; ((I)x).F(); } } The main method compiles to this: IL_0000: ldloc.0 IL_0001: box C IL_0006: callvirt instance void I::F() IL_000b: ret Why doesn't it compile to this? IL_0000: ldloca.s V_0 IL_0002: call instance void C::I.F() IL_0007: ret

Please help me understand this piece of code in the kotlin docs:- val a: Int = 10000 print(a === a) // Prints 'true' val boxedA: Int? = a val anotherBoxedA: Int? = a print(boxedA === anotherBoxedA) // !!!Prints 'false'!!! Now, I understand that first int a = 10000 then in the next line it is comparing it using === . Now the question is why when it assigned boxedA=a , it checked if it is null using int? . Can it just be written like this:- val boxedA: Int=a Please if I'm understanding it the wrong way, someone guide to check the right place or explain it a bit for me. when it assigned boxedA =

Those of us who've worked in VB/VB.NET have seen code similar to this abomination: Dim name As String = IIf(obj Is Nothing, "", obj.Name) I say "abomination" for three simple reasons: IIf is a function , all of whose parameters are evaluated; hence if obj is nothing in the above call then a NullReferenceException will be thrown. This is unexpected behavior for someone who's accustomed to short-circuited ternary operators in languages like C#. Because IIf is a function, it thus incurs the overhead of a function call. Again, though this isn't a big deal, it just doesn't feel right to someone who

Actually, I should've asked: how can I do this and remain CLS Compliant? Because the only way I can think of doing this is as follows, but using either __makeref , FieldInfo.SetValueDirect or just System.TypedReference in general invalidates CLS Compliance. // code illustrating the issue: TestFields fields = new TestFields { MaxValue = 1234 }; // test struct with one field FieldInfo info = fields.GetType().GetField("MaxValue"); // get the FieldInfo // actual magic, no boxing, not CLS compliant: TypedReference reference = __makeref(fields); info.SetValueDirect(reference, 4096); The compliant