Interfaces

[Imperceptus]

What is this Auto-Boxing?

[MyndFyre]

What is this Auto-Boxing?

Autoboxing is a Java feature that works like this:

Code Select Expand


// input code:
static void main(String[] args)
{
    int x = 5;
    int y = 10;

    doStuff(x, y);
}

static void doStuff(Integer x, Integer y)
{
    System.out.println(x.toString() + ", " + y.toString());
}


The effective generated code is:

Code Select Expand


static void main(String[] args)
{
    int x = 5;
    int y = 10;

    Integer @__x = new Integer(x);
    Integer @__y = new Integer(y);
    doStuff(@__x, @__y);
}

static void doStuff(Integer x, Integer y)
{
    System.out.println(x.toString() + ", " + y.toString());
}


In Java, the primitive "int" doesn't semantically mean the same as "Integer", whereas in .NET, there is no distinction between a primitive and the actual structure.  The structure for "int" is always System.Int32.  C# creates a "type alias" called "int" for System.Int32 (VB.NET's is "Integer"), it's all the same.

There's autoboxing in .NET, but it happens when you assign a value-type to Object:

Code Select Expand


int x = 5;
object o = x; // the value 5 is now on the heap
int y = (int)o; // the value from the heap is unboxed.


[Camel]

The converse is also true; if you cast a java.lang.Integer to an int, the compiler will auto-unbox it with a call to .intValue().

There's autoboxing in .NET, but it happens when you assign a value-type to Object:

Code Select Expand


int x = 5;
object o = x; // the value 5 is now on the heap
int y = (int)o; // the value from the heap is unboxed.


Does that count as auto-(un?)boxing? Correct me if I'm wrong, but it looks like that code is not pulling something out of an "object" box, but rather just casting the same reference as different types. In the Java sample, java.lang.Integer is a box that wraps the primitive int, which otherwise could not be 'null'.

[MyndFyre]

Does that count as auto-(un?)boxing? Correct me if I'm wrong, but it looks like that code is not pulling something out of an "object" box, but rather just casting the same reference as different types. In the Java sample, java.lang.Integer is a box that wraps the primitive int, which otherwise could not be 'null'.

That's boxing and unboxing, yes.  But boxing in .NET is generally considered to be bad practice since it's generally unnecessary.

You wouldn't do this in Java:

Code Select Expand


int x = 5;
Integer y = x;
Object z = y;
int fooBar = (int)((Integer)z);

That would be silly, but is effectively what I'm doing in that code.  There are very rarely reasons to store an integer on the heap unless it's part of another object.

[Camel]

There are very rarely reasons to store an integer on the heap unless it's part of another object.

You can't put the primitive in a class?

[MyndFyre]

There are very rarely reasons to store an integer on the heap unless it's part of another object.

You can't put the primitive in a class?

You can:

There's autoboxing in .NET, but it happens when you assign a value-type to Object:

Code Select Expand


int x = 5;
object o = x; // the value 5 is now on the heap
int y = (int)o; // the value from the heap is unboxed.


Are we talking about that or this:

Code Select Expand


public class Foo {
   public int Bar;
}

Both are valid.  The latter is used regularly.  The former is what I was referring to.  When you say "object o = 5;" that's "boxing" in .NET and it's generally considered bad practice since you don't need to put an integer on the heap.

[Camel]

If you try to set an int to null, to you get an NPE?

I'm going to assume the answer is yes, since I believe you said they are stack-bound which means they are not objects (even if the language allows you to operate on them as if they were). So, then, let's say you have a method that returns an integer most of the time, but can sometimes returns null -- but that does not indicate an error, and thus doesn't warrant throwing an exception. Does the return type of that method have to be Object, then? How does a naive caller know that the method can only return ints, if there is no super-primitive?

[MyndFyre]

If you try to set an int to null, to you get an NPE?

I'm going to assume the answer is yes, since I believe you said they are stack-bound which means they are not objects (even if the language allows you to operate on them as if they were). So, then, let's say you have a method that returns an integer most of the time, but can sometimes returns null -- but that does not indicate an error, and thus doesn't warrant throwing an exception. Does the return type of that method have to be Object, then? How does a naive caller know that the method can only return ints, if there is no super-primitive?

You can't set an int to null.  You get a compiler error. 

If you do this:

Code Select Expand


object o = 5;
o = null;

You set the object reference o to null, which is workable because o is bound to type object, not int.

.NET 2.0 introduced a concept of "nullable types" that utilize a generic:

Code Select Expand


public struct Nullable<T> where T : struct
{
    public bool HasValue { get; }
    public T Value { get; }
}

That structure generally has compiler support within languages to do implicit casting and whatnot; in C#, it's represented by the ? operator.  So your method signature might look like this:

Code Select Expand


public static int? DoSomething(int v) { ... }

However, if the return type was "int" the caller knows that the method will only return int.  There is no such thing as a null int - only a null int?.

Value-types still function as objects, though; they have vtables, it's just that the vtables belong to the owning class, not to a specific instance on the stack (although even that is moderately true of heap objects).  To put it another way:

All .NET heap objects are stored on the stack as pointers to their memory datum.  So assuming I have a string off in memory, what actually is living on the stack is a pointer to that memory - probably to an integer specifying how long the string is.  One machine word previous to that reference is a pointer to the object's "runtime type handle" which then provides me access to its vtable.

Stack-bound objects - structures or otherwise - don't have this.  So, I can cast between them (if my language allows).  The following isn't valid C#, but it conveys my meaning.  Assuming I have this struct:

Code Select Expand


public struct Point { int x; int y; override string ToString() { return "(" + x + ", " + y + ")"; } }


Assume the following code is valid (the compiler wouldn't let me do it):

Code Select Expand


Point p = new Point { x = 5, y = 10 };
int x = p;
Console.WriteLine(x.ToString());

Off the cuff, I'd say that the output would be 5.  The correct vtable is bound at compile-time based on the type determined by the owning type.  HOWEVER, if I wrote this code (this will compile and execute correctly):

Code Select Expand


Point p = new Point { x = 5, y = 10 };
object x = p;
Console.WriteLine(x.ToString());

The output would be the correct (5, 10) because the correct type is stored during the boxing procedure.

[Camel]

Ah, I see. Because there are other stack-bound types besides primitives, it's not sufficient to simply create super-primitives in .NET.

IMO, it's worth the trivial performance hit to just put everything on the heap to save the language from becoming cryptic. Objects and types that have obvious life-cycles don't need to go through the garbage collector anyways. For example, in the following:

Code Select Expand


int getValue() {
    Integer x = new Integer(4);
    return x.intValue();
}

x would be allocated on the heap, but would be destroyed an freed at the end of the method. Of course, if you actually wrote the above code, hotspot would never allocate the integer at all; it would optimize it out. It'd also probably inline the method.

[MyndFyre]

IMO, it's worth the trivial performance hit to just put everything on the heap to save the language from becoming cryptic.

It's interesting that every Java programmer to whom I've explained the distinction between stack types and heap types in .NET has followed by criticizing this as cryptic, yet I've never seen that "problem" be experienced....

[Imperceptus]

For the record most of what yall have discussed about the heap in the last few responses is very cryptic to me.  However my level of experience is novice compared to yall.

[Camel]

IMO, it's worth the trivial performance hit to just put everything on the heap to save the language from becoming cryptic.

It's interesting that every Java programmer to whom I've explained the distinction between stack types and heap types in .NET has followed by criticizing this as cryptic, yet I've never seen that "problem" be experienced....

What's the practical advantage of doing it that way? I see several drawbacks, but the only advantage I can see is a trivial performance boost, assuming the developer knows how to take advantage of it. It's not intuitive; the concept of a modern language reverting to the ways of C (where you' have to stop and look at the type declaration to figure out if something lives on the stack or the heap) irritates me. If heap performance is such a big concern, why would you use such a high level language in the first place?

[edit] I should also point out that I'm not opposed to the jitter using structs and heap-bound types at runtime. I just think that you shouldn't be expected to know the difference to write code.

[Imperceptus]

Camel, I for one don't know the difference.  But I do wish I do understand it a more in depth level.

[MyndFyre]

[edit] I should also point out that I'm not opposed to the jitter using structs and heap-bound types at runtime. I just think that you shouldn't be expected to know the difference to write code.

You aren't expected to know the difference.  I don't understand why it keeps coming up.

99% of the people I've worked with have never declared a struct.  There are specific reasons to do it, and most business applications don't need them.  Getting pointers to structures, for instance, is a huge optimization (because the garbage collector doesn't have to work around them).  But again - this is a very unusual situation and most people don't have to do it.

There's a distinction between *having* to do something and *being able* to do something.

[Camel]

A the GC would never have to worry about the equivalent object to a stack-bound struct, because its scope will end within the method, and the GC will therefore not have to 'watch' its life-cycle.