Unassigned variables Confusion

  • Thread starter Thread starter Rene
  • Start date Start date
R

Rene

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.
 
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
 
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
 
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/<[email protected]>

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 said:
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?
Click to expand...

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.
 
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!!!
 
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
 
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.
 
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/<[email protected]>

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
 
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
 
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/<[email protected]>

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.
 
Rene said:
Jon, you definitely
have enlightened me several times now, how could I ever repay you??
Click to expand...

Imagine if every time Jon helped someone out on here, they gave him £1 --
he could be a millionaire by now! <g>
 
Back
Top