I am learning about C# refs right now.
Is it safe to assume that all variables that are assigned with a new are references and not values?
Example:
SomeType variable = new SomeType()
views:
191answers:
6
+1
A:
No, value types are not references.
But with any other non-valuetype type and 'ref/out' parameter, they are references.
leppie
2009-05-14 04:32:24
+1
A:
No. In C# structs are also instantiated using new(), but are treated as values.
Tal Pressman
2009-05-14 04:32:50
A:
Looks like you are confusing references with objects. If that is the case than yes types that are created with the new keyword are objects. With the exception of structures which are treated as values.
Jeremy
2009-05-14 04:33:27
A:
Not necessarily. As you learn more about C# you'll find you have classes, which are reference types, and structs, which are value types. Both of them are instantiated through the use of the 'new' keyword, but instances of structs are not references.
jrcalzada
2009-05-14 04:33:56
+4
A:
No:
- Instance of classes are references, but instances of structs are values.
- Classes and structs can both be constructed using new
For example, System.Drawing.Point is a struct not a class:
Point point = new Point(1, 1); //point is a value, not a reference
ChrisW
2009-05-14 04:35:14
Are classes and structs the only two classes of variables?
Unknown
2009-05-14 05:02:15
There are other value types, for example 'int' and 'bool' (which can be but aren't usually initialized using 'new'), and 'enum' values: http://msdn.microsoft.com/en-us/library/s1ax56ch(VS.71).aspx
ChrisW
2009-05-14 05:20:28
+3
A:
C# has two types of objects - Reference Types (defined with a class keyword) and Value Types (defined with a struct keyword).
- RTs are created on the managed heap. When you do a new() on a RT, you get back a reference to an object on the heap. Two RT variables can point to the same object.
- VTs are created on the stack (unless they are a field within a reference type). When you do a new() on a VT, you get a variable that is pointing to the beginning of the object on the stack. Two value type variables can't point to the same object - they're always two distinct objects on the stack. This however is an implementation detail the important thing to remember is that VTs have value type semantics.
Pick up a good book on C# for more details.. Its an important concept.
Gishu
2009-05-14 04:37:02
"When you do a new() on a VT, you get a variable that is pointing to the beginning of the object on the stack." Does this mean that you can get corrupted memory if you reference the VT once the stack frame has been exited like in C?
Unknown
2009-05-14 04:47:01
Microsoft has come a long way... the CLR has checks to avoid such corruption and verifies code before it is executed. You can still screw up if you jump into unmanaged code and tinker, however that would required you to mark that section of code with an 'unsafe' keyword and require a compiler switch to be activated. In which case, you're saying you take responsibility for your unsafe code.
Gishu
2009-05-14 04:51:40
To summarize, 99% of the time if you are holding a VT variable/ref, you can be sure that it is pointing to a valid object. The CLR takes care/manages that for you.
Gishu
2009-05-14 04:53:23
@Gishu, but I don't understand about VTs being created on the stack. If they are truly created on a stack, any reference to the VT will be corrupted once you exit the function frame.
Unknown
2009-05-14 05:01:40
I think what you're missing is that VT have value-type semantics. So local VT variables within a func are on stack - lost after the function exits. VT arguments to a function are passed by value - a copy is created and given to the function - lost after the function exits. If you're holding a VT object across multiple function calls, it probably is a member variable of a reference type - in which case the struct is allocated on the managed heap as a section of the RT's instance data and hence is not lost across function calls. Does that answer your question ?
Gishu
2009-05-14 05:19:34
@Unknown, I don't see how you can reference a value instance, after the stack frame which contains that instance has returned: instead you could only reference a (different) *copy* of that value.
ChrisW
2009-05-14 05:23:36
Value types aren't always created on the stack. It's pretty complicated - see http://stackoverflow.com/questions/203695/structure-vs-class-in-c
Jon Skeet
2009-05-14 05:35:43