By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,847 Members | 2,261 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,847 IT Pros & Developers. It's quick & easy.

Unassigned variables Confusion

P: n/a
I understand that if I don't assign a *local* variable before I use it, the
compiler will generate a "Use of unassigned local variable" error. What I
don't get is why doesn't the compiler just implicitly assign a default value
to my unassigned variable?

At this point you are getting ready to reply to me and tell me that this is
just a way for the compiler to protect me from introducing a possible bug by
preventing me from forgetting to assign the value. The problem is that if
that was true, why doesn't it do the same thing for field level variables? I
mean, surely I could screw up there too right?

I have been scouring the web for a good answer and I have been unlucky in
finding a good response. Thank you for you time.
Nov 16 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Hi Rene,

Field level variables will be initialized to default values when the
instance is contructed. Since the compiler takes care of this, you don't have
to explicitly assign the values.

HTH,
Rakesh Rajan

"Rene" wrote:
I understand that if I don't assign a *local* variable before I use it, the
compiler will generate a "Use of unassigned local variable" error. What I
don't get is why doesn't the compiler just implicitly assign a default value
to my unassigned variable?

At this point you are getting ready to reply to me and tell me that this is
just a way for the compiler to protect me from introducing a possible bug by
preventing me from forgetting to assign the value. The problem is that if
that was true, why doesn't it do the same thing for field level variables? I
mean, surely I could screw up there too right?

I have been scouring the web for a good answer and I have been unlucky in
finding a good response. Thank you for you time.

Nov 16 '05 #2

P: n/a
So why doesn't the compiler do the same thing for the local variables?

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:D7**********************************@microsof t.com...
Hi Rene,

Field level variables will be initialized to default values when the
instance is contructed. Since the compiler takes care of this, you don't
have
to explicitly assign the values.

HTH,
Rakesh Rajan

"Rene" wrote:
I understand that if I don't assign a *local* variable before I use it,
the
compiler will generate a "Use of unassigned local variable" error. What I
don't get is why doesn't the compiler just implicitly assign a default
value
to my unassigned variable?

At this point you are getting ready to reply to me and tell me that this
is
just a way for the compiler to protect me from introducing a possible bug
by
preventing me from forgetting to assign the value. The problem is that if
that was true, why doesn't it do the same thing for field level
variables? I
mean, surely I could screw up there too right?

I have been scouring the web for a good answer and I have been unlucky in
finding a good response. Thank you for you time.

Nov 16 '05 #3

P: n/a
Hi Rene,

Look at it like this:
You declare a local variable only when you are going to make any practical
use of the value it contains.
If the compiler had been setting default values for local variables as well,
they will either be set to null (for classes) etc., which will surely throw
an error as soon as you try to access it's members.

Hence, to make sure that you yourself initialize the local var's, we have
this design.

HTH,
Rakesh Rajan

"Rene" wrote:
So why doesn't the compiler do the same thing for the local variables?

"Rakesh Rajan" <Ra*********@discussions.microsoft.com> wrote in message
news:D7**********************************@microsof t.com...
Hi Rene,

Field level variables will be initialized to default values when the
instance is contructed. Since the compiler takes care of this, you don't
have
to explicitly assign the values.

HTH,
Rakesh Rajan

"Rene" wrote:
I understand that if I don't assign a *local* variable before I use it,
the
compiler will generate a "Use of unassigned local variable" error. What I
don't get is why doesn't the compiler just implicitly assign a default
value
to my unassigned variable?

At this point you are getting ready to reply to me and tell me that this
is
just a way for the compiler to protect me from introducing a possible bug
by
preventing me from forgetting to assign the value. The problem is that if
that was true, why doesn't it do the same thing for field level
variables? I
mean, surely I could screw up there too right?

I have been scouring the web for a good answer and I have been unlucky in
finding a good response. Thank you for you time.


Nov 16 '05 #4

P: n/a
In fact the compiler does already initialize local variables to 0 or null (see the .locals init in the IL). But the C# compiler is being extra cautious and requesting you be explicit to how you want them initialized. And yes, it is inconsistent with how it treats member variables.

However, for statics, for example, the IL produced if you use a static field initializer is different form if you don't and there are performance optimizations based on this. So I think in terms of member variables they decided to be consistent within instance and statics and keep a then strict view on locals making people explicitly initialize them. This was, of course, consistent with best practice from C++ (the grandfather of C#) where locals would be garbage unless you initialized them.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<66**********************************@microsoft.co m>

Hi Rene,

Look at it like this:
You declare a local variable only when you are going to make any practical
use of the value it contains.
If the compiler had been setting default values for local variables as well,
they will either be set to null (for classes) etc., which will surely throw
an error as soon as you try to access it's members.

Hence, to make sure that you yourself initialize the local var's, we have
this design.

HTH,
Rakesh Rajan

Nov 16 '05 #5

P: n/a
Rene <no****@nospam.nospam> wrote:
I understand that if I don't assign a *local* variable before I use it, the
compiler will generate a "Use of unassigned local variable" error. What I
don't get is why doesn't the compiler just implicitly assign a default value
to my unassigned variable?

At this point you are getting ready to reply to me and tell me that this is
just a way for the compiler to protect me from introducing a possible bug by
preventing me from forgetting to assign the value. The problem is that if
that was true, why doesn't it do the same thing for field level variables? I
mean, surely I could screw up there too right?


Yes, but you basically *can't* protect yourself against that. If you've
got two methods, one of which sets a variable and the other of which
returns it, how would you expect the compiler to know in what order
those methods are called by other classes?

It's not that the compiler is doing the wrong thing with local
variables - it's that it doesn't have enough information to do the
right thing with static/instance variables.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 16 '05 #6

P: n/a
Well, I am still unclear on the issue. The only reason why I would declare a
field level variable is because I also have intentions to use it, otherwise
why would I bother?

Having said that, the compiler should enforce the same rules as the one
found for the Local variables! I don't get it!!!
Look at it like this:
You declare a local variable only when you are going to make any practical
use of the value it contains.
If the compiler had been setting default values for local variables as
well,
they will either be set to null (for classes) etc., which will surely
throw
an error as soon as you try to access it's members.

Nov 16 '05 #7

P: n/a
Exactly...and because you are going to use it, it should be ensures that you
set a value to it before it is accessed.

public void MyMethod()
{
Class1 obj;
Console.WriteLine(obj.Property1); // This would cause an error
}

HTH,
Rakesh Rajan

"Rene" wrote:
Well, I am still unclear on the issue. The only reason why I would declare a
field level variable is because I also have intentions to use it, otherwise
why would I bother?

Having said that, the compiler should enforce the same rules as the one
found for the Local variables! I don't get it!!!
Look at it like this:
You declare a local variable only when you are going to make any practical
use of the value it contains.
If the compiler had been setting default values for local variables as
well,
they will either be set to null (for classes) etc., which will surely
throw
an error as soon as you try to access it's members.


Nov 16 '05 #8

P: n/a
Ok, I get it now. If by some magical way the compiler could know that I
would be calling the "get" method first, the compiler could raise an error
to let me know that I am about to do something stupid and I should call the
"set" method first. Boy, I feel like such as dumb ass. (Jon, you definitely
have enlightened me several times now, how could I ever repay you??)

Thank you all.

PS: Richard, thanks for pointing out the ILDASM stuff. I will check it out
as soon as I get a chance.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Rene <no****@nospam.nospam> wrote:
I understand that if I don't assign a *local* variable before I use it,
the
compiler will generate a "Use of unassigned local variable" error. What I
don't get is why doesn't the compiler just implicitly assign a default
value
to my unassigned variable?

At this point you are getting ready to reply to me and tell me that this
is
just a way for the compiler to protect me from introducing a possible bug
by
preventing me from forgetting to assign the value. The problem is that if
that was true, why doesn't it do the same thing for field level
variables? I
mean, surely I could screw up there too right?


Yes, but you basically *can't* protect yourself against that. If you've
got two methods, one of which sets a variable and the other of which
returns it, how would you expect the compiler to know in what order
those methods are called by other classes?

It's not that the compiler is doing the wrong thing with local
variables - it's that it doesn't have enough information to do the
right thing with static/instance variables.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 16 '05 #9

P: n/a
Yes, but this is equally valid:

public void MyMethod()
{
Class1 obj = null;
Console.WriteLine(obj.Property1);
}

And in fact the compiler will have already emitted the IL instruction to do the same as the first line of the method, so simply declaring the variable *could* be enough for everything to work in a defined way. The issue is why does the C# compiler force you to assign a *specific* value when it has already ensured that it will default to null (in this case).

To me the answer is that C# is all about the code being explicitly obvious by looking at it, not having to infer details from knowledge outside of what you are looking at. This is one of the benefits for example of have to use the ref keyword at a method call site as well as in the method definition (of course the other reason is that you can overload ref and non-ref versions of a method and it needs to be able to tell the difference in that case).

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<0E**********************************@microsoft.co m>

Exactly...and because you are going to use it, it should be ensures that you
set a value to it before it is accessed.

public void MyMethod()
{
Class1 obj;
Console.WriteLine(obj.Property1); // This would cause an error
}

HTH,
Rakesh Rajan

Nov 16 '05 #10

P: n/a
Hi Richard,

I agree with your point that assigning null to the variable is being
internally done by the IL, and is the same as leaving the variable without
initializing it.

But, what I had been trying to say is that, this won't eliminate the error
that will happen when you try to access an object that is uninitialized.

This could be overridden when you are forced to explicitly initialize a
variable.

- Rakesh Rajan

"Richard Blewett [DevelopMentor]" wrote:
Yes, but this is equally valid:

public void MyMethod()
{
Class1 obj = null;
Console.WriteLine(obj.Property1);
}

And in fact the compiler will have already emitted the IL instruction to do the same as the first line of the method, so simply declaring the variable *could* be enough for everything to work in a defined way. The issue is why does the C# compiler force you to assign a *specific* value when it has already ensured that it will default to null (in this case).

To me the answer is that C# is all about the code being explicitly obvious by looking at it, not having to infer details from knowledge outside of what you are looking at. This is one of the benefits for example of have to use the ref keyword at a method call site as well as in the method definition (of course the other reason is that you can overload ref and non-ref versions of a method and it needs to be able to tell the difference in that case).

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<0E**********************************@microsoft.co m>

Exactly...and because you are going to use it, it should be ensures that you
set a value to it before it is accessed.

public void MyMethod()
{
Class1 obj;
Console.WriteLine(obj.Property1); // This would cause an error
}

HTH,
Rakesh Rajan

Nov 16 '05 #11

P: n/a
I agree that it forces you to think about how you want that variable initialized and its better in that respect to get a compile time error rather than a runtime one. I suppose the issue the OP was having is why aren't you forced to provide field initializers for member variables in that case

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<02**********************************@microsoft.co m>

Hi Richard,

I agree with your point that assigning null to the variable is being
internally done by the IL, and is the same as leaving the variable without
initializing it.

But, what I had been trying to say is that, this won't eliminate the error
that will happen when you try to access an object that is uninitialized.

This could be overridden when you are forced to explicitly initialize a
variable.

Nov 16 '05 #12

P: n/a
Rene <no****@nospam.nospam> wrote:
Jon, you definitely
have enlightened me several times now, how could I ever repay you??


Imagine if every time Jon helped someone out on here, they gave him 1 --
he could be a millionaire by now! <g>
Nov 16 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.