Converting code from C#.NET to VB.NET
-
Last week I was converting a code project from this site to VB.NET for use in my project, using SharpDevelop's built-in tool. I discovered a couple of problems with it that do not generate compiler errors (compiler errors are easy to spot and fix): 1) In C# you can assign multiple variables the same value like so:
var1 = var2 = var3 = value;
It gets translated to:
var1 = var2 = var3 = value
Which has a completely different meaning in VB.NET! = is used for both assignment and comparison. In this statement, only the left value is assignment, and the others are comparison! This means that the only value that changes is var1, probably to FALSE or 0 instead of value (it could also be TRUE or -1. Exercise for the reader to figure out how). 2) Let's say in C# we have:
float f = 0.75; int i = (int)f;
Translates into:
Dim f as Single = 0.75
Dim i as Integer = CInt(f)Which looks ok, until we check the value of i. It's 0 at the end of the C# code, but 1 at the end of the VB.NET code! This is because casting to an int in C# rounds floats down, but in VB.NET it rounds to the nearest integer. This may or may not cause problems, based on what the code is doing and how important it is to get an exact number. When you do end up with unacceptable rounding errors, you can simply replace the offending CInt with Math.Floor, which replicates C#'s behavior.
-
I second that.
-
Last week I was converting a code project from this site to VB.NET for use in my project, using SharpDevelop's built-in tool. I discovered a couple of problems with it that do not generate compiler errors (compiler errors are easy to spot and fix): 1) In C# you can assign multiple variables the same value like so:
var1 = var2 = var3 = value;
It gets translated to:
var1 = var2 = var3 = value
Which has a completely different meaning in VB.NET! = is used for both assignment and comparison. In this statement, only the left value is assignment, and the others are comparison! This means that the only value that changes is var1, probably to FALSE or 0 instead of value (it could also be TRUE or -1. Exercise for the reader to figure out how). 2) Let's say in C# we have:
float f = 0.75; int i = (int)f;
Translates into:
Dim f as Single = 0.75
Dim i as Integer = CInt(f)Which looks ok, until we check the value of i. It's 0 at the end of the C# code, but 1 at the end of the VB.NET code! This is because casting to an int in C# rounds floats down, but in VB.NET it rounds to the nearest integer. This may or may not cause problems, based on what the code is doing and how important it is to get an exact number. When you do end up with unacceptable rounding errors, you can simply replace the offending CInt with Math.Floor, which replicates C#'s behavior.
The_Mega_ZZTer wrote:
float f = 0.75; int i = (int)f;
f = 0should be wrong, isn't it? What I have learnt in Math is that 0.4 should be 0 and 0.5 should be 1. What do you say?Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net) If you want to thank me for my help, please vote my message by clicking one of numbers beside "Rate this message". Why vote? Plz Read it here. Thank you. :)
-
Last week I was converting a code project from this site to VB.NET for use in my project, using SharpDevelop's built-in tool. I discovered a couple of problems with it that do not generate compiler errors (compiler errors are easy to spot and fix): 1) In C# you can assign multiple variables the same value like so:
var1 = var2 = var3 = value;
It gets translated to:
var1 = var2 = var3 = value
Which has a completely different meaning in VB.NET! = is used for both assignment and comparison. In this statement, only the left value is assignment, and the others are comparison! This means that the only value that changes is var1, probably to FALSE or 0 instead of value (it could also be TRUE or -1. Exercise for the reader to figure out how). 2) Let's say in C# we have:
float f = 0.75; int i = (int)f;
Translates into:
Dim f as Single = 0.75
Dim i as Integer = CInt(f)Which looks ok, until we check the value of i. It's 0 at the end of the C# code, but 1 at the end of the VB.NET code! This is because casting to an int in C# rounds floats down, but in VB.NET it rounds to the nearest integer. This may or may not cause problems, based on what the code is doing and how important it is to get an exact number. When you do end up with unacceptable rounding errors, you can simply replace the offending CInt with Math.Floor, which replicates C#'s behavior.
The_Mega_ZZTer wrote:
Which has a completely different meaning in VB.NET! = is used for both assignment and comparison. In this statement, only the left value is assignment, and the others are comparison!
This is the whole reason why C# has == for equality comparisions. The whole issues is then avoided :P Another option for converting the code would be to use one of the decompiler plugins for Reflector. But then they often have issues with the decompiled code so SharpDevelop is probably less work.
-
Last week I was converting a code project from this site to VB.NET for use in my project, using SharpDevelop's built-in tool. I discovered a couple of problems with it that do not generate compiler errors (compiler errors are easy to spot and fix): 1) In C# you can assign multiple variables the same value like so:
var1 = var2 = var3 = value;
It gets translated to:
var1 = var2 = var3 = value
Which has a completely different meaning in VB.NET! = is used for both assignment and comparison. In this statement, only the left value is assignment, and the others are comparison! This means that the only value that changes is var1, probably to FALSE or 0 instead of value (it could also be TRUE or -1. Exercise for the reader to figure out how). 2) Let's say in C# we have:
float f = 0.75; int i = (int)f;
Translates into:
Dim f as Single = 0.75
Dim i as Integer = CInt(f)Which looks ok, until we check the value of i. It's 0 at the end of the C# code, but 1 at the end of the VB.NET code! This is because casting to an int in C# rounds floats down, but in VB.NET it rounds to the nearest integer. This may or may not cause problems, based on what the code is doing and how important it is to get an exact number. When you do end up with unacceptable rounding errors, you can simply replace the offending CInt with Math.Floor, which replicates C#'s behavior.
Casting in c# truncates and vb rounds. If you really want a pain Math.Round(4.5) == Math.Round(3.5)
File Not Found
-
The_Mega_ZZTer wrote:
float f = 0.75; int i = (int)f;
f = 0should be wrong, isn't it? What I have learnt in Math is that 0.4 should be 0 and 0.5 should be 1. What do you say?Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net) If you want to thank me for my help, please vote my message by clicking one of numbers beside "Rate this message". Why vote? Plz Read it here. Thank you. :)
Well, the technical answer is that casting is not rounding. What you say about rounding is a math definition, that can be accessed by an appropriate math function of the math library or namespace or whatever in many languages. Casting is an operation whose semantics depend on the level of efficiency the designer of the languages had in mind while designing compilers. Probably -IMHO- VB designers attempted to let expressions closer to math appearance, (VB derives from the 80's BASIC that inherits the idea of expressions from the 70's FORTRAN that was designed to help scientist to write formulas in programs) while C# inherits the C idea of "the fastest way to convert for the processor", that is "truncate the fractional part". The key point behind of this, is that "converting between languages" is not only a matter of "syntax" but also of "semantics". So, it cannot be done automatically without any analysis of what an expression stands for.
2 bugs found. > recompile ... 65534 bugs found. :doh:
-
Casting in c# truncates and vb rounds. If you really want a pain Math.Round(4.5) == Math.Round(3.5)
File Not Found
Thats right, .5 gets rounded to the even number right?
-
Thats right, .5 gets rounded to the even number right?
That is the basics of it. I think the documentation says odd numbers round up and even numbers round down. It is based on the IEEE Standard for rounding which doesn't match the simple grade school math. It really makes for headaches as most business customers what grade school math so as not to confuse their clients.
File Not Found
-
Last week I was converting a code project from this site to VB.NET for use in my project, using SharpDevelop's built-in tool. I discovered a couple of problems with it that do not generate compiler errors (compiler errors are easy to spot and fix): 1) In C# you can assign multiple variables the same value like so:
var1 = var2 = var3 = value;
It gets translated to:
var1 = var2 = var3 = value
Which has a completely different meaning in VB.NET! = is used for both assignment and comparison. In this statement, only the left value is assignment, and the others are comparison! This means that the only value that changes is var1, probably to FALSE or 0 instead of value (it could also be TRUE or -1. Exercise for the reader to figure out how). 2) Let's say in C# we have:
float f = 0.75; int i = (int)f;
Translates into:
Dim f as Single = 0.75
Dim i as Integer = CInt(f)Which looks ok, until we check the value of i. It's 0 at the end of the C# code, but 1 at the end of the VB.NET code! This is because casting to an int in C# rounds floats down, but in VB.NET it rounds to the nearest integer. This may or may not cause problems, based on what the code is doing and how important it is to get an exact number. When you do end up with unacceptable rounding errors, you can simply replace the offending CInt with Math.Floor, which replicates C#'s behavior.
- I fixed that in the converter in SharpDevelop 3.0 The new converter converts that statement to:
var1 = InlineAssignHelper(var2, InlineAssignHelper(var3, value))
and inserts this helper function in the code:
Private Shared Function InlineAssignHelper(Of T)(ByRef target As T, value As T) As T target = value Return value End Function- I didn't know CInt() is rounding, I'll fix this. The SharpDevelop 2.x compiler has more errors like this. E.g. if you have
int a, b, c;
return a / b * c;SharpDevelop outputs
Return a / b * c
which has a different result because / in VB is a floating-point division. SharpDevelop 3.0 will output
Return (a \ b) * c
\ = VB's integer division, which has a different operator precedence so the new converter is smart enough to add parenthesis.
-
Well, the technical answer is that casting is not rounding. What you say about rounding is a math definition, that can be accessed by an appropriate math function of the math library or namespace or whatever in many languages. Casting is an operation whose semantics depend on the level of efficiency the designer of the languages had in mind while designing compilers. Probably -IMHO- VB designers attempted to let expressions closer to math appearance, (VB derives from the 80's BASIC that inherits the idea of expressions from the 70's FORTRAN that was designed to help scientist to write formulas in programs) while C# inherits the C idea of "the fastest way to convert for the processor", that is "truncate the fractional part". The key point behind of this, is that "converting between languages" is not only a matter of "syntax" but also of "semantics". So, it cannot be done automatically without any analysis of what an expression stands for.
2 bugs found. > recompile ... 65534 bugs found. :doh:
emilio_grv wrote:
The key point behind of this, is that "converting between languages" is not only a matter of "syntax" but also of "semantics". So, it cannot be done automatically without any analysis of what an expression stands for.
Exactly. That's why the converter in SharpDevelop 3.0 takes a look at the referenced assemblies to understand the semantics of the code.
-
That is the basics of it. I think the documentation says odd numbers round up and even numbers round down. It is based on the IEEE Standard for rounding which doesn't match the simple grade school math. It really makes for headaches as most business customers what grade school math so as not to confuse their clients.
File Not Found
I never understood why they taught me .5 goes up and then when I got to higher level math and science classes they told me to go the even number. Why can't they just teach it the proper way from the beginning?
-
I never understood why they taught me .5 goes up and then when I got to higher level math and science classes they told me to go the even number. Why can't they just teach it the proper way from the beginning?
eggsovereasy wrote:
Why can't they just teach it the proper way from the beginning?
Because of the pervasive belief that children are too stupid to understand anything even mildly complex. In my own experience, if you treat a child like they can understand something, they usually do, and far more quickly than you expect them to. Their brains are far more flexible than ours, after all.
-
The_Mega_ZZTer wrote:
float f = 0.75; int i = (int)f;
f = 0should be wrong, isn't it? What I have learnt in Math is that 0.4 should be 0 and 0.5 should be 1. What do you say?Thanks and Regards, Michael Sync ( Blog: http://michaelsync.net) If you want to thank me for my help, please vote my message by clicking one of numbers beside "Rate this message". Why vote? Plz Read it here. Thank you. :)
I fought with the rounding issue for about a week trying to understand it. Then I found the MS documentation that states that MS uses bankers rounding. Bankers rounding means rounding to the nearest even number. Hence all values from 1 to 3 round to 2 and all values 3 to 5 round to 4 and so on. Its a frustrating problem, but casting should not be affected.
Phil
-
- I fixed that in the converter in SharpDevelop 3.0 The new converter converts that statement to:
var1 = InlineAssignHelper(var2, InlineAssignHelper(var3, value))
and inserts this helper function in the code:
Private Shared Function InlineAssignHelper(Of T)(ByRef target As T, value As T) As T target = value Return value End Function- I didn't know CInt() is rounding, I'll fix this. The SharpDevelop 2.x compiler has more errors like this. E.g. if you have
int a, b, c;
return a / b * c;SharpDevelop outputs
Return a / b * c
which has a different result because / in VB is a floating-point division. SharpDevelop 3.0 will output
Return (a \ b) * c
\ = VB's integer division, which has a different operator precedence so the new converter is smart enough to add parenthesis.
Awesome! I didn't think a #Dev dev would see this! Thanks. :)
-
I second that.
I am tired of this sort of remarks.
-
Last week I was converting a code project from this site to VB.NET for use in my project, using SharpDevelop's built-in tool. I discovered a couple of problems with it that do not generate compiler errors (compiler errors are easy to spot and fix): 1) In C# you can assign multiple variables the same value like so:
var1 = var2 = var3 = value;
It gets translated to:
var1 = var2 = var3 = value
Which has a completely different meaning in VB.NET! = is used for both assignment and comparison. In this statement, only the left value is assignment, and the others are comparison! This means that the only value that changes is var1, probably to FALSE or 0 instead of value (it could also be TRUE or -1. Exercise for the reader to figure out how). 2) Let's say in C# we have:
float f = 0.75; int i = (int)f;
Translates into:
Dim f as Single = 0.75
Dim i as Integer = CInt(f)Which looks ok, until we check the value of i. It's 0 at the end of the C# code, but 1 at the end of the VB.NET code! This is because casting to an int in C# rounds floats down, but in VB.NET it rounds to the nearest integer. This may or may not cause problems, based on what the code is doing and how important it is to get an exact number. When you do end up with unacceptable rounding errors, you can simply replace the offending CInt with Math.Floor, which replicates C#'s behavior.
-
I am tired of this sort of remarks.
Yeah, me too. C# is not intrinsically any better than VB.Net is - the syntax is just different. I have a business-rules engine that I maintain and enhance and it's ALL in VB.Net now. I would not have C# - it would make even more complicated the concepts I find relatively simple to implement in VB. I chose VB to get into Windows about 10 years ago - and I still choose it as the best all-'round language. I don't have to waste mental bandwidth dealing with multiple dialects whether I'm working with VB6, VBScript, VBA or VB.Net. That's OK, let the C# bigots continue flaming. Us VB guys will continue to get the job done. No big deal. -CB ;)
-
Last week I was converting a code project from this site to VB.NET for use in my project, using SharpDevelop's built-in tool. I discovered a couple of problems with it that do not generate compiler errors (compiler errors are easy to spot and fix): 1) In C# you can assign multiple variables the same value like so:
var1 = var2 = var3 = value;
It gets translated to:
var1 = var2 = var3 = value
Which has a completely different meaning in VB.NET! = is used for both assignment and comparison. In this statement, only the left value is assignment, and the others are comparison! This means that the only value that changes is var1, probably to FALSE or 0 instead of value (it could also be TRUE or -1. Exercise for the reader to figure out how). 2) Let's say in C# we have:
float f = 0.75; int i = (int)f;
Translates into:
Dim f as Single = 0.75
Dim i as Integer = CInt(f)Which looks ok, until we check the value of i. It's 0 at the end of the C# code, but 1 at the end of the VB.NET code! This is because casting to an int in C# rounds floats down, but in VB.NET it rounds to the nearest integer. This may or may not cause problems, based on what the code is doing and how important it is to get an exact number. When you do end up with unacceptable rounding errors, you can simply replace the offending CInt with Math.Floor, which replicates C#'s behavior.
Agree! Translation tool is not always reliable. A better translation of (int)f to VB.Net is Ctype(f, Integer). I do not think CInt() and Math.Floor are exact translation. Early this year, I translated the C# code of a book "Learning WCF" for O'Reilly into VB.Net. I did not use any translation tool at all. The reason is that when I do not know how to translate and try translation tools, they cannot give me the answer too.
petersgyoung
-
Yeah, me too. C# is not intrinsically any better than VB.Net is - the syntax is just different. I have a business-rules engine that I maintain and enhance and it's ALL in VB.Net now. I would not have C# - it would make even more complicated the concepts I find relatively simple to implement in VB. I chose VB to get into Windows about 10 years ago - and I still choose it as the best all-'round language. I don't have to waste mental bandwidth dealing with multiple dialects whether I'm working with VB6, VBScript, VBA or VB.Net. That's OK, let the C# bigots continue flaming. Us VB guys will continue to get the job done. No big deal. -CB ;)
I have programmed in Basic since mid 70(and with a lot of other languages). Basic and the VB have been the bulk of my code. Until this year. I now you C# for everything and would never go back to VB.
When prediction serves as polemic, it nearly always fails. Our prefrontal lobes can probe the future only when they aren’t leashed by dogma. The worst enemy of agile anticipation is our human propensity for comfy self-delusion. David Brin Buddha Dave