zero int?
-
Generally, you're right. The exception for that rule is if you declare an int array. It will then initialize every int in the array to 0. Kind of nice that you don't have to go through every row in the array to begin with.
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'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.
-
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;
-
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 initializenum, 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. -
Uninitialized local variables actually aren't null, but uninitialized. So you can't do
if (num == null)if you didn't initializenum, 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:
// set these variables in the declaration section bool isEmpty = false; int\[\] num; bool isEmpty2; int num2; private void SetEndElement(bool strt, bool outer, bool vert) { // have these in a routine, it will compile without error if (num == null) isEmpty = true; // I expected a runtime error here, but it runs, isEmpty2 is false, num2 is 0 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.
-
There is a difference between local and declared variables. int IS set to zero here:
// set these variables in the declaration section bool isEmpty = false; int\[\] num; bool isEmpty2; int num2; private void SetEndElement(bool strt, bool outer, bool vert) { // have these in a routine, it will compile without error if (num == null) isEmpty = true; // I expected a runtime error here, but it runs, isEmpty2 is false, num2 is 0 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).
-
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 :laugh:
-
b10543748 wrote:
and a store procedure with +/- 2600 lines.
I assume you are talking SQL. I haven't counted lines, but I've had printouts of over 45 pages. Personally, if your sproc prints out more than 5 pages, you've screwed up the design. At least in an OLTP environment. (I've never said anything like that to my employer, I'll just think it.)
-
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 :laugh:
-
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?