C#->VB.NET Porting Gotchas: Math

OK, this is not supposed to be one of those C# vs. VB.NET bashing contests, so please don’t let it turn into such.  I’m planning on creating a series of posts on areas where when you port code from C# to VB.NET you might run into some problems.  So to kick it off, I’m going to talk about two very common coding differences you might run into in the mathematical realm.

Take the following C# code:

int result = 64 + ((int)Math.Log10((double)score) * spacing);

Looks innocent enough.  To convert it to VB.NET you’d probably end up with:

Dim result As Integer = 64 + CInt(Math.Log10(CDbl(score))) * spacing

However, there are several gotchas contained within here.  First, (int) in C# works more similar to Fix() in VB.NET.  So in order to get the same behavior, you need to modify your code so that the floating point portion is truncated, not rounded.

Dim result As Integer = 64 + CInt(Fix(Math.Log10(CDbl(score)))) * spacing

Now that that is out of the way, there is still another problem looming in here.  Another behavior of the C# (int) cast is that it will work, by default, unchecked.  What does this mean?  Well, VB.NET by default will check for overflow checks at runtime, while C# doesn’t.  Not really sure why this is desirable other than performance.  Personally, I prefer VB.NET default to checking it.  Now two separate questions may be raised.  How do I handle this in VB.NET? and What about performance?

Well, if you want to have the same exact behavior, it’s pretty easy to accomplish.  Just go into the properties for your project and under Configuration Properties - Optimizations you’ll see a Remove integer overflow checks option.  Turn it on.  This will yield the same exact behavior that C# does by default.  It will also give you increased performance by not having to use the checked IL instructions.

I can tell your thinking to yourself that I said I prefer the VB.NET default to checking… but you know that I’m also interested in performance as well.  How can this be?  Well, to clarify my statement a bit.  I prefer having my debug build using integer overflow checks and remove them in release build.  This way I can test for these checks myself when I think they will potentially happen.

Now back to the code conversion, what is wrong with it in the context of integer overflow checking?  Well, if the score is 0, the result of Log10 is -Infinity and if the score is a negative number, the result is NaN (Not a Number).  Obviously these values are not within the numeric range of an integer.  I’d modify the code to check for these conditions before attempting to do the math.

Dim result As Integer
If score > 0 Then
  result = (64 + (CInt(Fix(Math.Log10(CDbl(score)))) * spacing))
Else
  result = 64
End If

After I tested all of the code with integer overflow enabled, I’d remove them in checked builds.

Another math related issue I see that raises it ugly head is in the area of the division operator. Here is a simple example in C# that could cause us problems:

int v = 10000000 / 31;

To convert this to VB.NET, you’d probably result in the following code:

Dim v As Integer = 10000000 / 31

Looks correct, right?

Well, try it.  You’ll find that in C# the result is 322580 and in VB.NET the result is 322581. The difference is how the division operator works in the two languages.  C# does integer division by default, where as VB.NET does floating point devision by default.  All is not lost however since VB.NET has an integer division operator, it’s the \ (backslash).  So modifying the code as:

Dim v As Integer = 10000000 \ 31

Will yield the same result.  Now, you probably won’t see code containing numeric values like this, it’d most likely be a couple of variables and longer equations.  So now you can see why this is potentially a very difficult “bug” to track down after you’ve ported the code.  As a general rule, you can replace the / (slash) operator in C# with the \ (backslash) operation in VB.NET.

That’s probably enough for this installment.  If you know of any more gotchas concerning math differences between C# and VB.NET, be sure to leave a comment.  Please refrain from other types of gotchas and save them for future installments.  If you’d like to send me issues that you’ve experienced (or are experiencing), please feel free to send me a comment using the contact link to the left.