|
No that's not true, it only zeroes out the array if you create it, not if you declare it. If you declare it, there is no array, just a variable that could hold it. So there's nothing to zero.
And the array would still have to satisfy the rules of definite assignment. (not its elements of course, which is what you seem to be talking about)
|
|
|
|
|
I was thinking in terms of int[] num = new int[10]; not int[] num;
You're agreeing with me that the 10 ints in the first case will all be zero.
if (num == null) would be true in the latter case because there isn't any value types to compare.
if (num[0] == null) would blow up because the array doesn't exist, I don't think it would compile because a value type can't be null.
I don't think that first "if" would work if you declared int num;
|
|
|
|
|
Uninitialized local variables actually aren't null, but uninitialized. So you can't do if (num == null) if you didn't initialize num, you would get "Error: Use of unassigned variable 'num'".
You actually can compare an int with null, that just gives a warning that it's always false.
|
|
|
|
|
There is a difference between local and declared variables. int IS set to zero here:
bool isEmpty = false;
int[] num;
bool isEmpty2;
int num2;
private void SetEndElement(bool strt, bool outer, bool vert)
{
if (num == null) isEmpty = true;
if (num2 == null) isEmpty2 = true;
The following produces 2 warnings and 2 errors and won't compile
Warning 1 The variable 'isEmpty' is assigned but its value is never used ... (stats on where the error is)
...
Error 3 Use of unassigned local variable 'num' ...
private void SetEndElement(bool strt, bool outer, bool vert)
{
bool isEmpty = false;
int[] num;
bool isEmpty2;
int num2;
if (num == null) isEmpty = true;
if (num2 == null) isEmpty2 = true;
So we're both wrong. 
harold aptroot wrote: warning that it's always false.
|
|
|
|
|
KP Lee wrote: So we're both wrong.
I don't see how you got to this conclusion.
Maybe I have to make it clearer.
- statically uninitialized local variables can not be used.
- comparing an int with null gives a warning that it's always false.
- the thread was about local variables.
- fields in a class are not called "declared variables", but are implicitly set to default(T).
|
|
|
|
|
harold aptroot wrote: - comparing an int with null gives a warning that it's always false.
That statement is where you are wrong. It NEVER says that. At least on my compiler.
With local variables, that results in a fatal error (using uninialized local variables) Absolutely no warning about the comparison. See my prior post for the exact error msg.
If YOUR compiler gives THAT warning, I appologize, I assumed you were using a Microsoft compiler. One new enough to compile (var x = "tst";) I definitely will not vouch for all versions.
harold aptroot wrote: - fields in a class are not called "declared variables", but are implicitly set to default(T).
POE TAE TOE/ PAW TAW TOE 
|
|
|
|
|
Well, what code are you using?
I'm talking about something like this:
int x = 0;
if (x == null) ;
|
|
|
|
|
CDP1802 wrote: Ironically, assingning zero to a variable of a numeric type is the most unproblematic case of all, since it turns out to be one or more zero bytes, no matter if we are looking at an integer type, a floating point type, signed or unsigned.
That's definitely true of assigning 0 to a variable. But there's a related case that's problematic:
sqlParams.Add(new SqlParameter("Quantity", 0));
Acutally assigns the "Quantity" parameter a value of null, because apparently this fits the definition for
SqlParameter(string parameterType, SqlDbType dbType) better than it does for
SqlParamter(string parameterType, object value) because 0 is a valid value for the enum SqlDbType and any match is a better match than object.
To assign a value of 0, you have to do:
sqlParams.Add(new SqlParameter("Quantity", Convert.ToInt32(0)));
(as for why you would do this... well, I'd rather not go into it...)
So maybe the original coder was confused by that very specific case? ...probably not...
|
|
|
|
|
Ironically, assingning zero to a variable of a numeric type is the most unproblematic case of all, since it turns out to be one or more zero bytes, no matter if we are looking at an integer type, a floating point type, signed or unsigned. The compiler knows the size (in bytes) of the variable the value is assigned to and there are no special ways to represent the number
assuming you aren't needing to deal with the IEEE arithmetic concepts of +0 and -0
|
|
|
|
|
Where would that apply? Floating point types?
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
That would apply in a 1's comp environment on it's integer type. Certainly not on a Windows OS which is 2's comp like every other system that realized 2's comp is a superior mathematical process.
On 1's comp with a 32 bit integer, -0 is for every bit set to 1. In 2's comp every bit as 1 in a signed integer is always -1
On 1's comp, this is how you get -0:
x=-1
x=x+1
When you print it, you get "0", not "-0", but internally it's still -0.
When you add 1 to -0, it first converts all the bits from 1 to 0 and then because you are changing signs, you add an additional 1 to the number so it becomes 1. -1 + 10 would produce 8 and then add 1 to get 9. You've got that extra step of adding or subtracting 1 to be done every time a mathematical operation changes case in either direction with the one exception of reaching -0.
2's comp uses no additional steps when changing cases
In SQL:
select (-2*1024)*1024*1024
select (2*1024)*1024*1024
will produce -2147483648 in the first result, the second will get the following error:
Msg 8115, Level 16, State 2, Line 2
Arithmetic overflow error converting expression to data type int.
Take out the parens and both fail with the same error.
In C# with type int, both will produce -2147483648 (Assuming checked isn't applied.)
modified 3-Dec-11 6:48am.
|
|
|
|
|
Even then +0 is just "all bits zero". It's just -0 that is slightly odd there.
|
|
|
|
|
harold aptroot wrote: It's just -0 that is slightly odd
Shouldn't it be slightly even? I am aware that there is a school of thought that 0 is neither odd nor even; but it divides by 2 with no remainder.
|
|
|
|
|
Slightly even must also be slightly odd, no? Or are you suggesting that it is part even part neither?
|
|
|
|
|
Maybe he didn't mean slightly odd, but evenly odd?
|
|
|
|
|
I think all zero bits in a float represents zero too (zero value and zero exponent).
|
|
|
|
|
That's the way I remembered it since the stone age.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
Indeed. I think there are multiple other ways to represent +-0 (e.g., if the significand is 0, any exponent should produce a result of -0 or +0, depending on the sign bit), though all zeroes should work.
Somebody in an online forum wrote: INTJs never really joke. They make a point. The joke is just a gift wrapper.
|
|
|
|
|
AspDotNetDev wrote: e.g., if the significand is 0, any exponent should produce a result of -0 or +0, depending on the sign bit
No, that won't work. There is an implicit leading 1-bit when the exponent is not zero, so if the exponent is nonzero it can never represent zero. Also if the exponent is all ones you'd get infinity if the mantissa is zero.
|
|
|
|
|
Good to know. 
Somebody in an online forum wrote: INTJs never really joke. They make a point. The joke is just a gift wrapper.
|
|
|
|
|
I'm not sure if float will represent an entered 0 as all "bits" 0. It's the only time the value will be all zero bits. I can't remember if the exponent value is 0 or 1, but in either case, I think the exponent needs at least 1 bit to be set to 1.
In any case, the -0 concept has nothing to do with float types. It's for signed integers in a 1's comp environment. I'm not sure if 1's comp was still being produced 30 years ago, I do know I learned about it around 1979 and it was known then how poor that mathematical model was.
Basically -0 is produced by having all 1's set in a signed integer. You get it by first getting a negative number and then adding to reach 0. In 1's comp, every negative number is the exact complement of the same positive number. (Position to position every 1 bit is set to 0 and every 0 bit is set to 1 to change from a positive number to the same negative number.
In 1's comp, the 1's bit is on for odd positive numbers and off for odd negative numbers. In 2's comp the 1's bit is on for both positive and negative numbers.
|
|
|
|
|
-0 has everything to do with floats.
OK there is also one's complement, which died a long time ago. And sign-magnitude integers, which also died.
FYI, 0.0f = 0x00000000 and -0.0f = 0x80000000
|
|
|
|
|
b10543748 wrote:
Int32 contador;
ftfy
The second line is pointless.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
A method to try it is written quickly. If the method only contains this declaration, it would work, but also be somewhat useless. Then add a single line that uses the variable and see what the compiler says
The second line is not pointless at all, at least if you intend to use the variable. If not, why declare it in the first place?
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
Sorry, I was misreading it. Int32 is an object type and so does need to be initialised in code; I was thinking of value type ints
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
