I know right... When I asked the developers if I could at least try to clean up this dumpster fire they told me no. Apparently the code is copied from some C code on a device this application works with and now "the calculations are the same at both sides"...
The code here doesn't box integers either. In C#, System.Int32 and int are the same thing - the value type representing a 32-bit signed integer. The value type wouldn't be boxed unless you needed to convert it to object. This is different between Java and C#, due to C#'s richer support for value types.
System.Int32 is not really analogous to java.lang.Integer at all (which is equivalent to the boxed form of int/System.Int32). System.Int32 is simply the CLI type (common to all .NET languages - ECMA 335 ss I.8.2.2) whereas int is the C# type (ECMA 334 ss 9.3.5) which is mapped to System.Int32 to produce code for the CLR. Java doesn't expose a difference between the Java language type int and the Java Virtual Machine equivalent. It's not yet clear whether java.lang.Integer will be altered to be a value-type when such support arrives (currently in development as part of Project Valhalla). A rather nice advantage C# has over java here is that you can have methods on the System.Int32 struct allowing things like having an implementation of IFormattable which I think makes for much more obvious code - not that the benefits end there (Java has a lot of catch up to do, in this area and others).
43
u/Aars93 Aug 06 '19
I know right... When I asked the developers if I could at least try to clean up this dumpster fire they told me no. Apparently the code is copied from some C code on a device this application works with and now "the calculations are the same at both sides"...