zero int?

[Lost User]

Int32 is a struct, not a class, making it a value type and not a reference type. It's also the underlying type in the framework for int, as far as I know you can use them synonymously.

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.

[Lost User]

It isn't, as noted, but it also wouldn't matter if it were. Local variables of reference types also "have to" be initialized. That is, they must satisfy the Definite Assignment rules. If it were a field in a struct/class or an array-element it wouldn't have to be initialized, but that is the case for any type; they're always set to default(type) in those cases.

[BobJanova]

int is a C# alias for the CLR type Int32, both refer to the same (value) type. You're thinking of Java's Integer and friends. And even with a reference class, you can't use a local variable before it's been explicitly assigned.

[PIEBALDconsult]

Well, actually, we don't know... it could be an Acme.Int32, the provided code doesn't specify. :rolleyes:

[Lost User]

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.

[Reiss]

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;
    }
}

}

[Lost User]

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.

[Lost User]

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
}

}

[Reiss]

+5 - That's just plain awful :)

[Chris Berger]

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...

[greldak]

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

[Lost User]

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.

[Lost User]

Even then +0 is just "all bits zero". It's just -0 that is slightly odd there.

[BobJanova]

I think all zero bits in a float represents zero too (zero value and zero exponent).

[Lost User]

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.

[AspDotNetDev]

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.

[Fabio Franco]

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

[Lost User]

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.

[jsc42]

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.

[Lost User]

Slightly even must also be slightly odd, no? Or are you suggesting that it is part even part neither?