[Mono-list] VBNC in Mono.

[Kornél Pál]

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:kornelpal at gmail.com]
Sent: Wednesday, September 13, 2006 1:23
To: Miguel de Icaza
Cc: mono-list at lists.ximian.com; 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" <miguel at novell.com>
To: "Kornél Pál" <kornelpal at gmail.com>
Cc: <mono-list at lists.ximian.com>
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)