What is the initial value of int

  • Thread starter Thread starter ad
  • Start date Start date
A

ad

When we declare a string, not giving it a value, the value of a string is
null like:
string myString;

When we declare a int like:
int myInt;

What is the value of myInt?
 
When we declare a string, not giving it a value, the value of a string is
null like:
string myString;

When we declare a int like:
int myInt;

What is the value of myInt?
Click to expand...

Its undefined (by definition, not in value). In fact the compiler will
complain if you try to use it without setting it first. The same goes for
string - its not 'null' - its undefined.
 
I don't know the answer to that, but wouldn't your code would fail to
compile with error, "CS0165: Use of unassigned local variable"?
 
The int which is an alias of System.Int32 is a stuct. In C#, all stuct
variables (value types) are implicitely initialized to the default value.
For int, it's 0.

Ram
 
I don't know the answer to that,
Click to expand...

It's zero.
but wouldn't your code would fail to compile with error, "CS0165: Use of
unassigned local variable"?
Click to expand...

Depends...

int intTest;
MessageBox.Show(Convert.ToString(intTest));

would fail as you suggest, but

int intTest = new int();
MessageBox.Show(Convert.ToString(intTest));
would be OK.
 
Not entirely true.

There are ways of getting at undefined members that the compiler can't
detect. For local variables, you are right. For class members, an
uninitialized int is 0 and an uninitialized string is null.

For example, the compiler will let you do this:

class Bar
{
private int foo;

public Bar() { }

public int FooValue
{
get { return this.foo; }
set { this.foo = value; }
}
}

So what do you get if you query myBar.FooValue before you set it? Zero.
 
The int which is an alias of System.Int32 is a stuct. In C#, all stuct
variables (value types) are implicitely initialized to the default
value. For int, it's 0.
Click to expand...

No its not - its a violation of the C# specification to use a variable
(even an int) before its assigned a value. 'null' is a valid value to
assign, but not for int type. There is no default value - it will result
in a compiler error.
 
Not entirely true.

There are ways of getting at undefined members that the compiler can't
detect. For local variables, you are right. For class members, an
uninitialized int is 0 and an uninitialized string is null.

For example, the compiler will let you do this:

class Bar
{
private int foo;

public Bar() { }

public int FooValue
{
get { return this.foo; }
set { this.foo = value; }
}
}

So what do you get if you query myBar.FooValue before you set it? Zero.
Click to expand...


My apologies - you are absolutely correct. I was blinded by the complexity
of the original question. :) Of course, it should be mentioned that
intentionally doing this is not good practice.
 
mdb said:
No its not - its a violation of the C# specification to use a variable
(even an int) before its assigned a value. 'null' is a valid value to
assign, but not for int type. There is no default value - it will result
in a compiler error.
Click to expand...

Not at all, member variables are initialized to 0 (zero), but the program
compiles with a warning like this:
warning CS0649: Field xxxxxx is never assigned to, and will always have its
default value 0
, for local variables however, must be explicitely assigned to before use,
here the compiler generates an error.

Willy.
 
mdb said:
My apologies - you are absolutely correct. I was blinded by the complexity
of the original question. :) Of course, it should be mentioned that
intentionally doing this is not good practice.
Click to expand...

Why? It's just relying on specified behaviour. I have no problem in
using the default values, personally.
 
Why? It's just relying on specified behaviour. I have no problem in
using the default values, personally.
Click to expand...


To understand why it's not such a good idea to rely on the default
values for any variables, consider the question asked in this thread,
and consider the confusion of answers.

Bottom line: it's not necessarily clear to the reader what those
values are. If you explicitly set them, then there is no such
confusion.
 
Wilbur Slice said:
To understand why it's not such a good idea to rely on the default
values for any variables, consider the question asked in this thread,
and consider the confusion of answers.
Click to expand...

That's only because the question wasn't specific - it didn't say
whether the variable in question was a local variable or not. I don't
think there'd have been disagreement if it had been specified.
Bottom line: it's not necessarily clear to the reader what those
values are. If you explicitly set them, then there is no such
confusion.
Click to expand...

I think we'll have to agree to disagree - I'd certainly hope that any
reader of my code would know C# well enough to know the default values
of instance/static variables.
 
Back
Top