Converting code from C#.NET to VB.NET
-
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
-
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
CInt() is not a function, it's a cast operator and completely equivalent to CType(, Integer). However, VB uses different rules for casting, so the correct translation of (int) is to NOT use the cast operator in VB but do something that produces the same result as C#'s cast. The best alternative I found so far is Math.Floor.
-
CInt() is not a function, it's a cast operator and completely equivalent to CType(, Integer). However, VB uses different rules for casting, so the correct translation of (int) is to NOT use the cast operator in VB but do something that produces the same result as C#'s cast. The best alternative I found so far is Math.Floor.
CInt() is a function that uses CType(, Integer) to return integer value for backward compatibility (VB6 function). I don't mean you cannot use Math.Floor. Before you do that, consider this: when you translate C# code to VB, all casting change to Math.Floor; and when you translate the translated VB back to C#, you cannot translate all Math.Floor back to casting. When you translate VB code to C#, you cannot use Math.Celling nor Math.Floor. VB is doing a better job in casting decimal to integer. I prefer casting 3.99 to 4 rather than casting it to 3.
petersgyoung
-
CInt() is a function that uses CType(, Integer) to return integer value for backward compatibility (VB6 function). I don't mean you cannot use Math.Floor. Before you do that, consider this: when you translate C# code to VB, all casting change to Math.Floor; and when you translate the translated VB back to C#, you cannot translate all Math.Floor back to casting. When you translate VB code to C#, you cannot use Math.Celling nor Math.Floor. VB is doing a better job in casting decimal to integer. I prefer casting 3.99 to 4 rather than casting it to 3.
petersgyoung
CInt is not a function. It's an operator just like CType,TryCast,etc. Take a look at the VB specification. Or take a look at these programs: This one compiles:
Module Program
Sub Main()
Dim d1 as Converter(Of Object, Integer) = AddressOf MyCInt
End SubFunction MyCInt(o As Object) As Integer return CType(o, Integer) End FunctionEnd Module
But this one fails with a syntax error:
Module Program
Sub Main()
Dim d1 as Converter(Of Object, Integer) = AddressOf CInt
End Sub
End ModuleOf course the conversion logic for VB->C# needs to use Convert.ToInt32() or Math.Round(). Of course not ALL Math.Floor() calls can be converted to casts, but I think all instances of "CInt(Math.Floor(x))" could be replaced with "(int)x".
-
CInt is not a function. It's an operator just like CType,TryCast,etc. Take a look at the VB specification. Or take a look at these programs: This one compiles:
Module Program
Sub Main()
Dim d1 as Converter(Of Object, Integer) = AddressOf MyCInt
End SubFunction MyCInt(o As Object) As Integer return CType(o, Integer) End FunctionEnd Module
But this one fails with a syntax error:
Module Program
Sub Main()
Dim d1 as Converter(Of Object, Integer) = AddressOf CInt
End Sub
End ModuleOf course the conversion logic for VB->C# needs to use Convert.ToInt32() or Math.Round(). Of course not ALL Math.Floor() calls can be converted to casts, but I think all instances of "CInt(Math.Floor(x))" could be replaced with "(int)x".
Thank you very much. You might be correct. But my point is that it is the responsibility of the programmer to make sure that he does not rely on casting to trim decimal if he wants to convert his codes to some other languages in the future. He needs to use Math.Floor() in his C# code. In fact, VB is a more forgiving language than C#. CType("3.4", Integer) is legal in VB, by (int)"3.4" is not.
petersgyoung
-
Thank you very much. You might be correct. But my point is that it is the responsibility of the programmer to make sure that he does not rely on casting to trim decimal if he wants to convert his codes to some other languages in the future. He needs to use Math.Floor() in his C# code. In fact, VB is a more forgiving language than C#. CType("3.4", Integer) is legal in VB, by (int)"3.4" is not.
petersgyoung
petersgyoung wrote:
But my point is that it is the responsibility of the programmer to make sure that he does not rely on casting to trim decimal if he wants to convert his codes to some other languages in the future.
No. If the program is valid in C#, the converter should either report an error ("Program not convertable") or convert it into a VB program that does the same as the C# program. The converter should not introduce any subtle bugs. All converters I know (including the one I've written for SharpDevelop 2.x) are incorrect. They don't analyze semantics, so they are unusable for any mildly complex program. That doesn't mean that one shouldn't use casts in C# code because someone might convert the program later; it means that we need a better converter.
petersgyoung wrote:
In fact, VB is a more forgiving language than C#. CType("3.4", Integer) is legal in VB, by (int)"3.4" is not.
That's why a correct converter must convert CType("3.4", Integer) to Microsoft.VisualBasic.CompilerServices.Conversions.ToInteger("3.4").
-
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 ;)
CodeBubba wrote:
Us VB guys will continue to get the job done.
you said something about 'bigots'. would you care to rephrase that ?