views:

470

answers:

5

Hi folks, Guids are created using the new keyword which makes me think it's a reference type.

Is this correct?

Guid uid = new Guid();

Are Guids stored on the heap?

+5  A: 

It's a value type.

http://msdn.microsoft.com/en-us/library/system.guid.aspx

jinsungy
+10  A: 

Guid is a Value Type.

See MSDN. Note that Guid is a struct. All structs are Value Types.

Randolpho
Except of course for System.ValueType which is in fact a class :)
JaredPar
@JaredPar: True, but it's also abstract, so no danger of instantiation.
Randolpho
nice observations, thanks.
SoftwareGeek
+14  A: 

You can see the definition of a Guid yourself:

public struct Guid ...

Or you can test it like this:

bool guidIsValueType = typeof(Guid).IsValueType;

GUID's are created using the new keyword which makes me think it's a reference type.

Structs can have constructors too, for example new DateTime(2012, 12, 23).

Juliet
+2  A: 

It's actually Guid. All types are constructed using the new keyword. You can identify reference types from value types by whether they are a class, interface, or delegate (all reference types), or a struct or enum (value types).

280Z28
You might want to add enum to your list of value types.
Jon Skeet
+4  A: 

GUID's are created using the new keyword which makes me think it's a reference type.

Stop thinking that. Value types can have constructors too. It is perfectly legal, though strange, to say

int x = new int();

That's the same as assigning zero to x.

Is this correct?

Nope.

Are GUID's stored on heap?

Yes. Guids are also stored on the stack.

Note that the analysis below assumes that the implementation of the CLI is the Microsoft "desktop" or "Silverlight" CLR running on Windows. I have no idea what other versions of the CLI do, what they do on Macs, and so on. If you need to know whether a particular hunk of memory is stored on the stack in other implementations, you'll have to ask someone who is an expert on those implementations.

A Guid is stored on the stack under the following circumstances:

(1) when the Guid is a "temporary" result of an ongoing calculation or is being used as an argument to a method. For example, if you have a method call M(new Guid()) then temporary storage for the new Guid is allocated on the stack.

(2) when the Guid is a local variable which is (a) not in an iterator block, (b) not a closed-over outer variable of an anonymous method or lambda expression.

In all other situations the Guid is not stored on the stack. A Guid is stored on the heap when it is a field of a reference type, an element of an array, a closed-over local of an anonymous method or lambda expression, or a local in an iterator block.

A Guid may also be stored in neither the GC heap nor the stack. A Guid might be stored in entirely unmanaged memory, accessed via unsafe pointer arithmetic.

I am curious as to why you care so much as to whether the bits of a guid are on the stack or on the heap. What difference does it make?

Eric Lippert
well, now that it's clear guid can be stored anywhere, i guess it wouldn't matter.
SoftwareGeek