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.
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
-
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
Sounds like we started around the same time. Originally I wrote in FORTRAN IV, then C and Assembler (for a LOT of years) writing device-drivers and memory-management code on early PC's. Spent about 5 years writing custom applications on my own - all in C. Then when I decided to address the Windows platform VB3 is what got me there. By that time I was really tired of re-inventing the wheel so VB was very refreshing. When I came onboard this firm the rules engine was in C, still. Converted it to VB6 so it could be a COM component then eventually into VB.Net so our ASP.Net stuff can use it without COM interop. One of my projects is in C# so I'm not unfamiliar with C#. It's "OK" ... I don't mind working with it - however anything new I create under .Net is still in VB.Net because I personally find it easier to work with and I just *like* the language dialect. It's my personal choice. Some of the young hot-shots in the shop try to sell me on using C# instead - I keep telling them to show me something they can accomplish that I can't as easily or MORE easily and they can never come up with anything - so I don't waste my time with it. When you've been doing this as long as I have you pick the tools that work best not just the ones that are "in fashion" as C# seems to be. MS has only been enhancing VB.Net not dropping it so that, as they say, is that as far as I'm concerned. Take Care, -CB ;)
-
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
CInt() and CType(, Integer) are equivalent, both are rounding. Even System.Convert.ToInt32 is using the VB semantics and rounds. (int)Math.Floor() is the best translation I could find so far, so I'll implement that in the next version of the SharpDevelop converter. Does anyone know a converter that gets this right? Even Reflector is decompiling (int)a incorrectly to CInt().
-
CInt() and CType(, Integer) are equivalent, both are rounding. Even System.Convert.ToInt32 is using the VB semantics and rounds. (int)Math.Floor() is the best translation I could find so far, so I'll implement that in the next version of the SharpDevelop converter. Does anyone know a converter that gets this right? Even Reflector is decompiling (int)a incorrectly to CInt().
CInt() and Math.Floor are functions. CType(, Integer) and (int) are casting. You can easily substitute Integer with other types, e.g. CType(x, String) is (string)x, CType(x, DateTime) is (DateTime)x, etc. Unfortunately, VB and C# are using different rules for casting decimal to integer!
petersgyoung