zero int?
-
True. In that case it would be a horror. Using a class or a struct with the name of a type defined in the framework without fully qualifiying the type to point out that it is not the type you would normally assume it to be, is downright deceptive. To be able to do that you also have to leave out the system namespace where the type in question is located and only use the namespace where the 'Acme' type is located. Include both and you have no choice but to fully qualify the types in your code.
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.I have just made this code up to show how horrific you can make it Define my own type using a name defined in the framework
namespace Dummy
{
public class Int32
{
public Int32()
{
}public string Value { get; set; } }}
Implement it somewhere
using system = Dummy; // note the lower case 's'
namespace AnotherDummy
{
public class Class1
{
public Class1()
{
string value = "Hello";system.Int32 x = new system.Int32(); x.Value = value; } }}
-
I have just made this code up to show how horrific you can make it Define my own type using a name defined in the framework
namespace Dummy
{
public class Int32
{
public Int32()
{
}public string Value { get; set; } }}
Implement it somewhere
using system = Dummy; // note the lower case 's'
namespace AnotherDummy
{
public class Class1
{
public Class1()
{
string value = "Hello";system.Int32 x = new system.Int32(); x.Value = value; } }}
Long ago we did our best to write misleading code with help of the C preprocessor. Then Java came along and they celebrated the end of such malicious practices. C# has a preprocessor (as all directives beginning with '#' clearly show), but it is harder to use in a destructive way. Still, your example shows that it was not the preprocessor that was the root of all evil.
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. -
I have just made this code up to show how horrific you can make it Define my own type using a name defined in the framework
namespace Dummy
{
public class Int32
{
public Int32()
{
}public string Value { get; set; } }}
Implement it somewhere
using system = Dummy; // note the lower case 's'
namespace AnotherDummy
{
public class Class1
{
public Class1()
{
string value = "Hello";system.Int32 x = new system.Int32(); x.Value = value; } }}
That's bad, but it can be worse:
namespace Dummy
{
public struct Int32
{
int val;private Int32(int v) { val = v; } public static implicit operator Int32(int x) { return new Int32(x - 3); } public static implicit operator int(Int32 x) { return x.val; } public static Int32 operator \*(Int32 a, Int32 b) { return new Int32(a.val \* (b.val + 1)); } // etc }}
-
That's bad, but it can be worse:
namespace Dummy
{
public struct Int32
{
int val;private Int32(int v) { val = v; } public static implicit operator Int32(int x) { return new Int32(x - 3); } public static implicit operator int(Int32 x) { return x.val; } public static Int32 operator \*(Int32 a, Int32 b) { return new Int32(a.val \* (b.val + 1)); } // etc }}
-
The declaration and initialisation could of course have been done in one line, but that makes little difference. From this I get the impression that the developer who wrote this is very 'modern'. He probably has no idea what the compiler will generate from those simple code lines and added the type cast just in case this assignment might be problematic. 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 'zero'. Therefore no special type information is needed in the assignment. Bottom line: I see this as clumsy code, but not as a real horror. It does what it is supposed to and I see no potentially harmful side effects. However, I would also see it as an indicator that the developer should perhaps learn more about what happens under the hood, even if that's not 'modern'.
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.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...
-
The declaration and initialisation could of course have been done in one line, but that makes little difference. From this I get the impression that the developer who wrote this is very 'modern'. He probably has no idea what the compiler will generate from those simple code lines and added the type cast just in case this assignment might be problematic. 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 'zero'. Therefore no special type information is needed in the assignment. Bottom line: I see this as clumsy code, but not as a real horror. It does what it is supposed to and I see no potentially harmful side effects. However, I would also see it as an indicator that the developer should perhaps learn more about what happens under the hood, even if that's not 'modern'.
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.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 'zero'. Therefore no special type information is needed in the assignment.
assuming you aren't needing to deal with the IEEE arithmetic concepts of +0 and -0
-
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 'zero'. Therefore no special type information is needed in the assignment.
assuming you aren't needing to deal with the IEEE arithmetic concepts of +0 and -0
-
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 'zero'. Therefore no special type information is needed in the assignment.
assuming you aren't needing to deal with the IEEE arithmetic concepts of +0 and -0
-
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 'zero'. Therefore no special type information is needed in the assignment.
assuming you aren't needing to deal with the IEEE arithmetic concepts of +0 and -0
-
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.
-
b10543748 wrote:
a store procedure with +/- 2600 lines.
That's the real horror here. It gives me goose bumps just to think about it.
b10543748 wrote:
Int32 contador; contador = (Int32)0;
I think that deserves the hall of shame, just for the fact that the person that wrote this probably had no idea what he was doing. But, what if, historically this code looked like this:
Int32 contador;
contador = (Int32)3.2;And then, for whatever reason it was change to 0 and the cast was just kept. Or even:
long outroContador = paramX * 1000000L;
.
.
.
Int32 contador;
contador = (Int32)outroContador;So, maybe, just maybe, it was just a matter of safety.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
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.
-
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.
-
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. :thumbsup:
Somebody in an online forum wrote:
INTJs never really joke. They make a point. The joke is just a gift wrapper.
-
No. You would get the 'use of an unassigned variable' error and it would not compile. Edit: To be precise: I made two assumptions: 1) This variable is declared inside a method, not as a class member. Initializing it separately leaves no other possibility than that. 2) If you declare a variable inside a method and don't initialize it, it's still ok for the compiler as long as you don't try to use it in the following code. Such an unused declaration would only trigger a compiler warning. The error would occur as soon as you tried to use the uninitialized variable (other than initializing it) in the following code.
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. -
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.)
-
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.
-
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)