Question about value types

[Zach]

When it is being said that, "value types are created on the stack [no
problem with that] or inline [what is being said here?] as part of an
object". If a value type is created in an object, and that object is being
called, the value type in that object, is still created on the stack, I
would say, so I don't understand this inline business. Apart from the fact
that it is my understanding that "inline" as it exists in C++ [e.g. inline
functions] doesn't exist in C#. Could someone please shed some light on this
basic issue for me?

 

[sadhu]

Creating instances of value types as local variables creates them on
the stack. If you have a value type as a field of a reference type,
then that is stored as part of the object. It can't be stored on the
stack, as the contents of the stack are valid only till the end of
execution of a method, however reference types outlive that (as they
are created on the heap). The same is the case with an array of value
types, they are stored inline on the heap.

And yes, there is no inline keyword, although the JIT compiler might
inline functions it chooses to.

Regards
Senthil

 

[Zach]

The same is the case with an array of value types, they are stored inline

on the heap.

Would you please explain the meaning of "inline" here?

 

[Bruce Wood]

I think that "inline" is an unfortunate bit of jargon that crept into
the explanation you read.

Think of value types as types that act (and are allocated) in the same
way as an integer or a float.

If you declare an int local variable in a method somewhere, the space
for that int is allocated on the stack. Similarly, if you declare an
int parameter to a method, the argument is _copied_ onto the stack when
the method is called. Value types act in exactly the same way.

However, if you declare an int as a field of a class, space for that
int is reserved within ("inline", as the description you read
unfortunately expressed it) the space allocated on the heap for each
instance of the class. So, each class instance has some space set aside
for it on the heap, and within that space is space for the int. The
same with value types.

Reference types act differently. All reference types are always
allocated on the heap. References (pointers) to those reference types
are then stored in variables, passed to methods, and stored in object
instances according to the same rules as value types. In effect, the
reference (pointer) to the reference type is the value, whereas for
value types the entire bit pattern for the type is the value.

Arrays (that is, native arrays, not ArrayList or other aggregate
structures) act the way you would expect them to given the above
behaviour. An array of ints (or any other value type) is allocated on
the heap as a block of memory big enough to hold all of the values it
must contain. An array of reference types (object instances) is
allocated as an array of references (pointers) to objects that are
stored elsewhere on the heap.

Finally, an array, being a reference type itself, is stored and passed
around as a reference (pointer).

 

[Zach]

<snipped>

I compiled the following text - would you agree with this text?

Variables and constants are storage locations with names. A constant is a
variable with a continuous value. A "read only" variable is a constant.
Variables can be classified in terms of location, size, scope, type, value,
duration (the time span during which they have a life) and how their value
is retrieved. Variables can be located on the heap or on the stack. The size
of the storage location is independent of the compiler or the operating
system, but is determined by their type (e.g. int, double). Scope and
duration are determined by where the variable is declared. Variables
declared in a method - or in the parameter list of a method - are local
variables. They have no life outside the method. Parameters can be straight
values, or additionally qualified as "out" (returns a value), or "ref"
(changes the value). The value of a variable can be numerical or
alpha-numerical (i.e. a string value). Variables like int are called
"intrinsic", or (=) "built-in" or (=) "primitive" types. Primitive types are
structs. Which means that all variable in C# are objects. The value of a
variable is retrieved directly from the stack ("value types"), or indirectly
via a pointer ("reference types"). Pointers represent values, which
themselves cannot be approached ditectly. Because of this difference value
types are more efficient. Pointers are stored on the stack, whereas the
values they represent are stored on the heap. A variable declared in an
object is stored together (some authors say "inline") with that object. For
example a system array refers to a contiguous block of memory on the heap,
large enough to hold the number and type of elements for which it was
declared. Its pointers are on the stack; its values are on the heap. But in
the case of an array of reference types, there are pointers on the stack -
to pointers on the heap - pointing to values on the heap.

 

[Bruce Wood]

Rats. I wrote a reply on Saturday, but evidently it was swallowed by
the Web.

Variables and constants are storage locations with names. A constant is a
variable with a continuous value.

Be careful. In C#, constants often do not have storage locations. They
can be (usually are) just compile-time constructs. For example, the
compiler will render

const int a = 5;
const int b = 6;
int c = a + b;

down to this:

int c = 11;

Variables do have storage locations; constants may not.

A "read only" variable is a constant.

Not exactly. The "readonly" keyword in C# guarantees that the variable
can be changed only in the class's constructor(s) and nowhere else.
However, if the "readonly" variable is a reference to an object on the
heap, the "readonly" keyword does _not_ guarantee that the object
itself cannot be changed outside the constructor, only that the
reference will never point to any other object than the one it was
pointing to when the constructor finished executing.

"readonly" built-in types (such as int and float) are in fact
invariable after the constructor terminates, and are a handy way to
create constants that require some complex calculations... constants
that can't simply be built at compile time.

The value of a variable can be numerical or alpha-numerical (i.e. a

string value).

A little simplistic, I think. From the lowest-level point of view,
variables just contain bit patterns that can be interpreted in various
ways. From a higher-level point of view, variables have an almost
infinite variation of types, as the .NET Framework class library
illustrates. As a trivial example, enumerated types don't fall into
either of these categories, and neither do structs that compose complex
value types.

Variables like int are called "intrinsic", or (=) "built-in" or (=) "primitive" types.
Primitive types are structs.

That's backward, to my way of thinking. Primitive types are not
structs; structs act in many ways like primitive (value) types. The two
have similar behaviour, but that doesn't imply an "is a" relationship,
in my mind, and especially not "primitive type is-a struct".

Which means that all variable in C# are objects.

Now, that's an interesting assertion. It all depends upon how you
define "object". I tend to refer to "objects" in C# as reference types,
but then it's true that in C# value types derive from Object and have
methods, including GetType(), so they have some properties of objects.
However, you can't inherit from them. So are they really full-fledged
"objects"? They certainly more object-like than primitive types in,
say, Java or C++.

The value of a variable is retrieved directly from the stack ("value types"), or indirectly
via a pointer ("reference types").

For local variables and method arguments, yes.

Pointers represent values, which themselves cannot be approached

directly. Because of this difference value types are more efficient.

Be careful here. Yes, value types are "more efficient" for many
operations, but this does _not_ mean that you should decide between
using a value type and using a reference type based on value types
being "more efficient". This is efficiency at a very low (I'd say even
"trivial") level. Real performance gains are usually had by looking at
efficiency at a far higher level of abstraction than this. In that
sense, the "most efficient" construct--value type or reference
type--for a job is the one that best fits the design. Deciding to use
value types becaues of some idea that they are generally "more
efficient" usually leads to tortured and--yes--inefficient code, in my
experience.

Pointers are stored on the stack, whereas the values they represent

are stored on the heap.

Again, yes, for reference types that are local variables or method
arguments.

A variable declared in an object is stored together (some authors say

"inline") with that object.

Yes. On the heap.

For example a system array refers to a contiguous block of memory on the heap,
large enough to hold the number and type of elements for which it was

declared. Its pointers are on the stack; its values are on the heap. But in
the case of an array of reference types, there are pointers on the stack -
to pointers on the heap - pointing to values on the heap.

Yes, keeping in mind that when you say "its pointers" above, you're
talking about the various references that your application is holding
to the array. Those are held on the stack (or, if they form part of an
object's state, on the heap with the other object state data).