Hi Kornél, > (But we should stick to vbc 7.x behavior in VB runtime to support .NET 1.x.)
I'm with you. Please commit. Do you think that we should place a notice on that coding practice, somewhere in the $mono-basic\vbruntime\readme.txt ? BTW, Some of the "TypeOf <value> Is <type>" in CompilerServices should be changed into Dim type1 As Type = Value.GetType() Select Case Type.GetTypeCode(type1) Rafael -----Original Message----- From: Kornél Pál [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 11:53 To: Rafael Mizrahi; Miguel de Icaza Cc: [email protected]; Rolf Bjarne Kvinge Subject: Re: [Mono-list] VBNC in Mono. Hi, >Help me understand, do you suggest that we will stop using CFoo functions >inside >CompilerServices ? >I see that >CStr CBool CLng CDbl changed into DirectCast >Convert.ToString changed into DirectCast >Value.ToString changed into DirectCast I don't suggest to to change things generally, I only suggest changing the particular usages I modified in the patch. (I didn't do a global audtit of the VB runtime I only did in CompilerServices.) CSrt, CBool, ... is the same as CType(..., String), CType(..., Boolean) so I'll refer to them as CType. CType is a conversion operator while DirectCast is a casting operator. DirectCast is compiled castclass, box, unbox, or conv.... While CType is compiled as calls in the VB runtime to do a more complex conversion than IL supports. Note that in some cases they are compiled as nop (nothing) or some conversion opcodes when specific data types are know to the compiler. For example CInt(<some Integer variable>) will result in nop. Also note that DirectCast was only suitable for castclass and box in vbc 7.x but vbc 8.0 supports it for value types as well. This is a bit weird to me because casting and conversion are two distinct things but it's useful because DirectCast ensures that no VB runtime conversion method is used. (But we should stick to vbc 7.x behavior in VB runtime to support .NET 1.x.) >But what is the reason for changing some of the .ToString into DirectCast ? If you check for the exact data type (as you did in all the cases I modified to DirectCast) either for value types of for reference types there is no use to do tricky conversions because we know the type of the variable so a DirectCast is the most efficient and most reasonable conversion because after a TypeOf <value> Is <type> a DirectCast(<value>, <type>) will succeed for sure. So I only suggest to change CType to DirectCast in these contexts. For more inforamtion see: C<type>: http://msdn2.microsoft.com/en-us/library/s2dy91zy.aspx CType: http://msdn2.microsoft.com/en-us/library/4x2877xb.aspx DirectCast: http://msdn2.microsoft.com/en-us/library/7k6y2h6x.aspx TryCast: http://msdn2.microsoft.com/en-us/library/zyy863x8.aspx Kornél -----Original Message----- From: Kornél Pál [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 1:23 To: Miguel de Icaza Cc: [email protected]; Rafael Mizrahi; Rolf Bjarne Kvinge Subject: Re: [Mono-list] VBNC in Mono. Hi, Use "VB.replace.bat 2" then try to bootstrap vbnc on MS.NET. For an example have a look at the attached vbrun.diff. The bug I found when trying to compile vbnc was: Case TypeCode.Decimal Return CDec(Value) This results in a recursiong with Conversions.ToDecimal because CDec (and all the other CType conversions are done at runtime unless the type is known to the compiler as well. And anyway there is no use to do reinterpretation when the exact type is know. A simple unbox is enough. But there are other bugs (and I guess a lot of them) in VB runtime for sure. And I found a bug in vbnc as well that was possible because of a bug in System.Windows.Forms.:) Kornél ----- Original Message ----- From: "Miguel de Icaza" <[EMAIL PROTECTED]> To: "Kornél Pál" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Wednesday, September 13, 2006 12:04 AM Subject: Re: [Mono-list] VBNC in Mono. > Hey! > >> But it's unable to bootstrap itself on MS.NET using our VB runtime so the >> VB >> runtime should be fixed as well before trying to fix vbnc on Mono. > > Do you have some details for me? > > This is a good observation, before we launch ourselves into a quest to > fix bugs on the Mono side (although we already fixed a known problem) _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
