4

Let's say I do something like this:

int x = 5;
String s = x.ToString();

Coming from Java, I would be led to think that an autoboxing is being done on the int value to make it behave like an object and call methods on it. But I've heard that in C# everything is an object, and there's no thing such as the Java "Integer" type. So, is the variable being boxed to Object instead? Or can methods be called directly from C# value types? How?

Is the C# int just a 32-bit space like in Java/C, or is it something more? Thank you in advance for clearing my doubts.

Vivin Paliath
  • 94,126
  • 40
  • 223
  • 295
  • For `value` types that explicitly implement `ToString()` and other methods that are typically inherited `System.Object`, boxing is avoided when calling the methods (assuming you haven't _already_ boxed them some other way) – willaien Feb 10 '16 at 18:54
  • In C#, the standard int type is always an Int32, and is always 32 bits. There are other int's to int16 etc... – Chris Hawkes Feb 10 '16 at 18:55

2 Answers2

1

int is a structure so it is declared on the stack, not the heap. Structures, however, in c# can have methods, properties, and fields just like a class can. The method ToString() is defined on type System.Object and all classes and structures alike are derived from System.Object. So calling .ToString() on a structure does not do any type of boxing (changing the value type to a reference type).

If you want to see boxing in c# it would be with casting or implicit conversion like so.

public void Testing() {
    // 5 is boxed here
    var myBoxedInt = (object)5;

    var myInt = 4;
    // myInt is boxed and sent to the method
    SomeCall(myInt);

}

public void SomeCall(object param1){}
nima
  • 6,566
  • 4
  • 45
  • 57
Igor
  • 60,821
  • 10
  • 100
  • 175
  • I never realized structs are derived from Object - I thought Object was a class... – Andrew Williamson Feb 10 '16 at 19:01
  • So, C# itself allows value types to call methods, in some way. It would be nice to know exactly how, though. –  Feb 10 '16 at 19:01
  • 2
    @JohnStrife - value types can have methods and therefor also have behavior. This behavior can then call other methods (`allows value types to call methods`). What do you mean by `how`? Are you looking for code on how to define a struct and define a method on a struct? – Igor Feb 10 '16 at 19:05
  • 3
    @AndrewWilliamson - technically structs derive from `System.ValueType` but this then derives from `System.Object`. – Igor Feb 10 '16 at 19:10
  • I would like to know exactly where does the language read the methods, when we call them on a value type object, since they're not defined in a "value class" like reference type. And is there a way to create our value-type objects with their own methods? –  Feb 12 '16 at 18:44
  • @JohnStrife - all types are inherited from `System.Object` which contains 4 methods. In that regard any object you deal with will always have those 4 methods. You can define your own structs using the same notation that you use for defining a class but instead of using the 'class' keyword you use 'struct' which tells the system to inherit from `System.ValueType`. From there you define members just like you would a class. – Igor Feb 12 '16 at 18:59
  • So... int, char, etc... are all structs? And every struct can have methods and internal values just like classes? What's that makes them lighter then? –  Feb 12 '16 at 19:01
  • 1
    @JohnStrife - Correct. They *can be* more light weight because they are allocated on the stack so as soon as they are out of scope the memory is reclaimed. I say can be because everything is subject to how it is used / misused., As far as the technical differences (like no inheritance, constructors with parameters, etc) see this [MS how to article](https://msdn.microsoft.com/en-us/library/aa288471(v=vs.71).aspx). – Igor Feb 12 '16 at 19:12
  • I see, thanks for the explanation. So, an example of misuse could be making a heavy struct which would better fit a class causing a... stack overflow? –  Feb 12 '16 at 19:21
  • 1
    @JohnStrife - Or a struct with long lived references to objects, a struct with many members that are mutable (lead to unexpected issues), a struct that takes up a lot of space in memory and then creating too many of them (as you generally have more memory reserved for heap than the stack (could indeed be an SO), a struct where the user assumes the object itself is mutable (not possible). i'm sure there are more but i can't think of anything else off the top of my head. – Igor Feb 12 '16 at 19:33
1

To elaborate on @Igor's answer and give you some specifics:

This code:

public void Test() {
    int x = 5;
    string s = x.ToString();
}

Can be thought of as this hypothetical code:

public void Test() {
    int x = 5;
    string s = StringInternals.ToString(x);
}

// ...

public static class StringInternals {

    public static string ToString( int x ) {
        // Standard int to -> string implementation
        // Eg, figure out how many digits there are, allocate a buffer to fit them, read out digits one at a time and convert digit to char.
    }

}
antiduh
  • 11,853
  • 4
  • 43
  • 66