Class Instances

[James Matthews]

Why when you create a class instance do you have to declare the class name
before.

newClass ras = new newClass();

Thanks
James

 

[Ben Voigt [C++ MVP]]

Why when you create a class instance do you have to declare the class name
before.

newClass ras = new newClass();

You don't.

object ras;
ras = new newClass();

works just fine.

You have to declare a variable, with the form "type varname;". After that
you can assign it an instance. Some languages distinguish between the
combined declare+assign, called initialization, and separate steps. C#
doesn't.

Thanks
James

And get what looks like spam out of your signature, please.

 

[Scott M.]

The first reference to the class is just a way of telling the CLR what kind
of reference your variable will have. The second reference to the class is
to actually instantiate it.

For example you might want to create a variable that points to an already
existing class:

//Here we want a new variable (x) and so we need to tell the CLR where to
set aside memory and how much memory
//to set aside, so we start off by saying what type x will point to. But,
then there is the question of what will
//actually be placed into that memory. If it should be a new class instance
you need to make that instance.
//And you can't make an instance without saying what you are making an
instance of, so we need the second
//part of the statement.
dataset x = new DataSet();

// On this next line we are not making a new instance, but we need to
indicate
// what kind of data the variable "o" will point to, so we must start by
saying the
// type (object)
object o = x;

 

[Guest]

Why when you create a class instance do you have to declare the class
name before.

newClass ras = new newClass();

Thanks
James

Because the first is the type of the reference, and the second is the
type of the object.

The code is equivalent to:

newClass ras;
ras = new newClass();

The types of the reference and the object are not always the same. For
example:

Form dialog = new EditUserDialog();

Here the reference is of the type Form, but the object is the derived
type EditUserDialog.


In C# 3 there will be the var keyword:

var builder = new System.Text.StringBuilder();

This will make the reference the same type as the object. It should
however only be used when the type of the object is obvious, and where
it actually improves readability.

 

[Gino]

Hope this helps.

The first part of the statement, "newClass ras" creates a varible "ras" of
type "newClass" on the stack.
It's value is set to null.
The second part of the statement "= new newClass" calls the constructor for
newClass which reads the code for newClass off of the hardrive and creates
an object (newClass) on the heap. The address (ex. 0x00a83000) of the object
(newClass) then replaces the null value of "ras" on the stack. You access
the methods, properties, and events of the newClass object by using the
varible "ras" then the dot operator. (the varible "ras" now holds a ref to
the object "newClass").

Microsoft has designed the .net framework around a strickly typed
architecture, and since C# is a new language it is much tighter than vb.net.
Each high level language has it's own compiler that compiles to the
intermediate language. At the intermeditate language the type has to be
known so that the (JIT) "Just In Time" compiler can do type checking as it
compiles the code to machice language each time the program is executed.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Hope this helps.

The first part of the statement, "newClass ras" creates a varible "ras" of
type "newClass" on the stack.
It's value is set to null.

Actually, it's not set to null. The value is undefined.

 

[Jon Skeet [C# MVP]]

The first part of the statement, "newClass ras" creates a varible "ras" of
type "newClass" on the stack.
It's value is set to null.

No - its value is unassigned, at least as far as the C# language is
concerned. An implementation could choose to clear the memory, but it
doesn't have to, as far as I'm aware. You won't be able to "see" the
contents of the memory until it's been definitely assigned anyway.

 

[Christof Nordiek]

No - its value is unassigned, at least as far as the C# language is
concerned. An implementation could choose to clear the memory, but it
doesn't have to, as far as I'm aware. You won't be able to "see" the
contents of the memory until it's been definitely assigned anyway.

Actually a 'debuggable' builds (in most cases that build from
'DEBUG'-Configuration), its preset with null. But only, so that the debugger
has something to show, if it's stop before the assignment and the programm
has a specific behavior if the execution point is changed through the
debugger.

Conceptually local variables don't have initial values (if they aren't
initialized explicitly.)

Christof

 

[Jon Skeet [C# MVP]]

Actually a 'debuggable' builds (in most cases that build from
'DEBUG'-Configuration), its preset with null. But only, so that the debugger
has something to show, if it's stop before the assignment and the
programm has a specific behavior if the execution point is changed through
the debugger.

Right - and I would say that's an IDE/compiler-specific feature,
rather than part of C# the language.

Conceptually local variables don't have initial values (if they aren't
initialized explicitly.)

Indeed. There's another case which is interesting in this respect, by
the way - out parameters and reflection. If you dynamically invoke a
method and use out parameters, you get to see the current value, which
indeed is 0/null/etc in .NET. It's tough for a language spec to
foresee all these possibilities, IMO.

Jon

 

[Gino]

Then what is a "null reference error" if there is no such thing as the value
of an instance in the stack being set to null.
example:
SqlConnection myConnection;
myConnection.Open();
Throws a "null reference error" because myConnection has not been
instantiated. When myConnection.Open(); is called the compiler goes to
"myConnection" in the stack and reads the value ( which is "null") and
returns a "null reference error".
null is not = to zero, or nothing.
null is = to a value not set.
When the class is instantiated
myConnection = new SqlConnection;
the constructor is called for SqlConnection, which creates the object
"SqlConnection" in the heap and writes the beginning address of the method
table for SqlConnection as the value for the "myConnection" instance in the
stack.
Now when myConnection.Open(); is called, the compiler goes to the intance
varible "myConnection" in the stack and reads the value, which is the
address of the method table for the SqlConnection object in the heap, and
finds the "Open" method and loads that on the Stack with it's parameters and
executes it.

 

[Peter Duniho]

Then what is a "null reference error" if there is no such thing as the
value
of an instance in the stack being set to null.

You misread. No one has said that "there is no such thing as the value of
an instance in the stack being set to null". They have simply pointed out
that it is not set to null by default, as far as the language definition
is concerned. It's not set to _anything_. You are required to set it
before using it.

example:
SqlConnection myConnection;
myConnection.Open();
Throws a "null reference error" because myConnection has not been
instantiated.

How do you get that to compile? C# disallows the use of uninitialized
local variables.

When myConnection.Open(); is called the compiler goes to
"myConnection" in the stack and reads the value ( which is "null") and
returns a "null reference error".

If by some odd mechanism you have managed to bypass the compiler's
checking that your variable is not initialized, and at the same time you
luck out and you're in a situation where the local variable just happened
to be null (for example, as Christof points out, you're running a "Debug"
build of your application), then yes...that will happen. I don't see how
you can get yourself into that situation, but as long as you maintain that
you can, I will take your word for it.

Still, that doesn't mean that you can rely on the local variable being set
to null, nor does it mean that you can normally even write code that uses
a local variable before it's been _explicitly_ set to something.

Pete

 

[Jon Skeet [C# MVP]]

Then what is a "null reference error" if there is no such thing as the value
of an instance in the stack being set to null.

Well, an instance isn't set to null, but a variable certainly can be. I
never said that it couldn't.

What I said was that a local variable doesn't start with a null value -
it starts off as unassigned.

example:
SqlConnection myConnection;
myConnection.Open();
Throws a "null reference error" because myConnection has not been
instantiated.

No it doesn't - it fails to compile with an error because myConnection
hasn't been definitely assigned. Try it and you'll see that.

Now, if myConnection were an *instance* variable that would be a
different matter.

 

[Christof Nordiek]

SqlConnection myConnection;
myConnection.Open();
Throws a "null reference error" because myConnection has not been
instantiated.

If the two lines above stood as you wrote them in a method, this what throw
a compiler error, because the local variable is unassigned.

A different thing would be, if the declaration were on class level, then the
field would be initialized to null. Then, if there is noe assignment to it
prior in time,a call to open would throw null reference exceptions.

Again: Local variables in C# aren't initialized implicitly and don't have
initial values.

Christof

 

[Christof Nordiek]

Indeed. There's another case which is interesting in this respect, by
the way - out parameters and reflection. If you dynamically invoke a
method and use out parameters, you get to see the current value, which
indeed is 0/null/etc in .NET. It's tough for a language spec to
foresee all these possibilities, IMO.

I don't understand what you mean. Could you show an example that
demonstrates this issue.

Christof

 

[Jon Skeet [C# MVP]]

I don't understand what you mean. Could you show an example that
demonstrates this issue.

Suppose you have an interface which has a method which takes out
parameters. You can use RealProxy to implement that interface in a
reflection-based way, where the parameter values come in an array (like
the opposite of MethodInfo.Invoke, effectively). That way you can see
the values of parameters which are theoretically uninitialized. I first
ran across this when doing some work on EasyMock.NET.

It's horrible though, and as I say I don't think the language spec
ought to be concerned with it.

 

[Ben Voigt [C++ MVP]]

I don't understand what you mean. Could you show an example that
demonstrates this issue.

I don't get that either, but I think you can read an uninitialized local or
out parameter quite trivially using pointers.