That being said, I still think what MyndFyre said is very true. C# is a superset of Java.
I don't care either way about the whole java vs. C# battle, I was just pointed out that one of his examples was wrong. Well, it's not even really wrong, just outdated.
It's not even really outdated. Here's why:
I know this post is a bit old, but I just want to point out that this is entirely wrong. Clicky.
Though currently the code should look something like this:
ArrayList<Object> al = new ArrayList<Object>();
al.add(1);
al.add(4485);
al.add("This is a string.");
Autoboxing is a feature of the
compiler, not the
runtime. The compiler itself emits the "new Integer(1)" code intrinsically whenever a reference type is expected in place of a primitive, and so if you were to decompile, you'd see calls such as list.add(new Integer(1)); in place of your original list.add(1); call.
Why is this distinction important? Well, by putting this in the compiler rather than in the runtime, Java has effectively put a barrier to EVER supporting the declaration of custom primitive types.
In most procedural OOP languages such as C++, Java, and C#, you have two types of variables: stack and heap. Stack variables are the local variables that exist within the local function scope. Heap variables can be shared across scope. I'll give you an example.
The following types in Java and C# are always stack variables: Java (byte, short, int, long, boolean, float, double), C# (byte, sbyte, short, ushort, int, uint, long, ulong, bool, float, double, decimal).
In Java, all other classes are heap variables, which all derive from java.lang.Object. That means when you declare a heap variable, a tiny little object reference is created on the stack which is effectively a pointer (more accurately it's a handle), but all of that object's other data exists in the pointed-to location in heap memory. This is also true in C#, for all classes that are declared "class" (classes that are declared "struct" are custom stack-level variables). Heap classes in C# work exactly the same way. However, structures do not.
Consider the following C# structure declaration:
public struct Point {
public int X;
public int Y;
public Point(int x, int y) { X = x; Y = y; }
}
If I were to create a new Point, both the X and Y components of that Point would exist on the stack. Consider the same definition but with a class keyword.
public class PointClass {
public int X;
public int Y;
public PointClass(int x, int y) { X = x; Y = y; }
}
Now consider the following code:
static void Main(string[] args) {
Point point = new Point(1, 2);
PointClass pointClass = new PointClass(1, 2);
ChangePoint(point);
ChangePointClass(pointClass);
Console.WriteLine("Point: ({0}, {1}); PointClass: ({2}, {3}).", point.X, point.Y, pointClass.X, pointClass.Y);
}
static void ChangePoint(Point p) { p.X += 1; p.Y += 2; }
static void ChangePointClass(PointClass p) { p.X += 1; p.Y += 2; }
The output of this would be:
Point: (1, 2); PointClass: (2, 4).
When stack variables are passed as parameters (this is true in C#, Java, C++, etc.), they are copied onto the stack (if you disassemble native code, you'll see these as push [register] instructions). When the return value is done, the stack variable still refers to the original stack memory location. Only the copy is modified. When you push heap variables as parameters, though, the contents of the heap variable is modified. This can be better demonstrated in C++:
class Point
{
public:
int X, Y;
Point(int x, int y) { X = x; Y = y; }
}
int main()
{
Point stackVar(1, 2);
Point* heapVar = new Point(1, 2);
}
In this example, stackVar exists locally and will be copied to any functions that accept it as a parameter as a Point (as opposed to a Point&, which isn't the same thing). On the other hand, heapVar exists on the heap, which is why you need to use dereference syntax (heapVar->X = 2;) in order to get at its contents.
ANYWAY, the point of all this is: in Java, because of this design decision, you're not soon going to be able to create custom stack variable types (C# structs). Why? Because the Java compiler, in order to wrap them, must know the type of the reference type to which your stack type is boxed.
Oh, last thing - if you were to get the runtime type of a variable boxed in either Java or C#:
// java
ArrayList al = new ArrayList();
al.add(1);
al.get(0).getClass(); // returns the Type reference of Integer - you still need to cast it back to int.
// C#
ArrayList al = new ArrayList();
al.Add(1);
al[0].GetType(); // returns Int32, the C# alias for which is "int"
