Interesting behaviour of type “decimal” in C#

Question

If we declare padding as const decimal, the padding is not working.

mymoney = 1.2 and your money = 1.20, how can this behavior be explained?

class Progra         


        

Answer 1

balance + ConstPadding == balance

Because ConstPadding is zero!

You should -

Console.WriteLine(yourmoney.ToString("0.00"));  //1.20

Answer 2

As an accompaniment to Jon's answer, below is the IL produced from your code. As he mentioned, mymoney was never added.

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       61 (0x3d)
  .maxstack  6
  .locals init ([0] valuetype [mscorlib]System.Decimal balance,
           [1] valuetype [mscorlib]System.Decimal padding,
           [2] valuetype [mscorlib]System.Decimal mymoney,
           [3] valuetype [mscorlib]System.Decimal yourmoney)
  IL_0000:  nop
  IL_0001:  ldc.i4.s   12
  IL_0003:  ldc.i4.0
  IL_0004:  ldc.i4.0
  IL_0005:  ldc.i4.0
  IL_0006:  ldc.i4.1
  IL_0007:  newobj     instance void [mscorlib]System.Decimal::.ctor(int32,
                                                                     int32,
                                                                     int32,
                                                                     bool,
                                                                     uint8)
  IL_000c:  stloc.0
  IL_000d:  ldc.i4.0
  IL_000e:  ldc.i4.0
  IL_000f:  ldc.i4.0
  IL_0010:  ldc.i4.0
  IL_0011:  ldc.i4.2
  IL_0012:  newobj     instance void [mscorlib]System.Decimal::.ctor(int32,
                                                                     int32,
                                                                     int32,
                                                                     bool,
                                                                     uint8)
  IL_0017:  stloc.1
  IL_0018:  ldloc.0
  IL_0019:  ldc.i4.2
  IL_001a:  call       valuetype [mscorlib]System.Decimal [mscorlib]System.Decimal::Round(valuetype [mscorlib]System.Decimal,
                                                                                          int32)
  IL_001f:  stloc.2
  IL_0020:  ldloc.0
  IL_0021:  ldloc.1
  IL_0022:  call       valuetype [mscorlib]System.Decimal [mscorlib]System.Decimal::op_Addition(valuetype [mscorlib]System.Decimal,
                                                                                                valuetype [mscorlib]System.Decimal)
  IL_0027:  ldc.i4.2
  IL_0028:  call       valuetype [mscorlib]System.Decimal [mscorlib]System.Decimal::Round(valuetype [mscorlib]System.Decimal,
                                                                                          int32)
  IL_002d:  stloc.3
  IL_002e:  ldloc.2
  IL_002f:  call       void [mscorlib]System.Console::WriteLine(valuetype [mscorlib]System.Decimal)
  IL_0034:  nop
  IL_0035:  ldloc.3
  IL_0036:  call       void [mscorlib]System.Console::WriteLine(valuetype [mscorlib]System.Decimal)
  IL_003b:  nop
  IL_003c:  ret
} // end of method Program::Main

To produce the IL (i.e. if you want to look under the hood in the future), just run ILDASM from a VS command prompt, then load your executable and double-click on the method that you would like to look at.

Answer 3

The sum operation with the constant padding is getting completely excluded from the MSIL, yet it is there for a non-constant field. I was not able to find any references to FCallAddSub function, unfortunately, but that's the one who "optimizes" the call.

Answer 4

If I'm not mistaken the complier isn't doing the addition with the constant decimal because it is zero.

Will post proof shortly.

Proof shown by Jon Skeet answer above.

Answer 5

The compiler "knows" that adding zero to a value "shouldn't" change the value - so it optimizes this out. Now arguably that's an invalid optimization given the nature of decimal addition, but if you look at the generated code, you'll find the computation of mymoney doesn't involve an addition.

I don't think I'd try to use adding 0.00m as a way to ensure a particular scale, to be honest. You could create your own code to enforce the scale, using decimal.GetBits and the constructor performing the reverse operation - but I don't think it would be terribly nice.

Do you definitely need this "two decimal places" form as an intermediate value, or is it only for presentation? If it's the latter, I'd look at format strings instead.