Page 2 of 2 FirstFirst 12
Results 41 to 53 of 53

Thread: [RESOLVED] VB.Variant vs C#.Object

  1. #41
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    7,378

    Re: [RESOLVED] VB.Variant vs C#.Object

    Quote Originally Posted by Shaggy Hiker View Post
    You need one other thing: A jump statement. I don't believe that any ASM language can be capable without one. They are the basis of conditionals, loops, and all other flow control.
    Jump statements are covered by my more general description of being able to manipulate the program counter. Jump instructions, call and ret instructions and interrupts are covered by this. They all work by changing the program counter. The program counter is just a register that holds the address of the next instruction to be executed by the CPU.
    Last edited by Niya; May 13th, 2022 at 09:57 AM.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  2. #42
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    7,378

    Re: [RESOLVED] VB.Variant vs C#.Object

    You know when I think about it a little more deeply, it can be broken down a tad bit more. These 3 things are all you need for a fully functional computer:-
    • The ability to read from and write to storage.
    • The ability to perform boolean algebra on two storage locations and write the result to storage.
    • The ability to change the program counter both conditionally and unconditionally.


    With those 3 things alone you can create a programming language of any complexity. You can derive a lot from just those 3 things. For example addition and subtraction can be derived from boolean algebra and multiplication and division can be derived from addition and subtraction. If-Then logic can be derived from subtraction and conditional jumping. Loops can be derived from both conditional and unconditional jumping. These things can then be built up towards even more advanced stuff like function calls which can be further be built into method calls on objects. You could just go on and on and on with additional complexity by building one system on top of another.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  3. #43
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    37,319

    Re: [RESOLVED] VB.Variant vs C#.Object

    Quote Originally Posted by Niya View Post
    Jump statements are covered by my more general description of being able to manipulate the program counter. Jump instructions, call and ret instructions and interrupts are covered by this. They all work by changing the program counter. The program counter is just a register that holds the address of the next instruction to be executed by the CPU.
    I thought you might have been covering it that way, but I do feel the jump is more fundamental than the program counter. The program counter is one way to manage sequence, and it's the way most commonly used, but jump is required whether or not program counters are the mechanism used to manage sequence.

    Still, it's just a matter of view. If the program counter is used as an abstract concept, then, yeah, it is interchangeable with jump. The underlying concept is that you must have a means to designate the next action taken.
    My usual boring signature: Nothing

  4. #44
    PowerPoster
    Join Date
    Feb 2006
    Posts
    23,283

    Re: [RESOLVED] VB.Variant vs C#.Object

    Program counters are pretty fundamental since they are used as the instruction-fetch index. They aren't always simple counters though.

    I think it was the IBM 650 that used a magnetic drum as primary store. Every instruction contained the address of the next instruction. The compilers and loader used this to try to decrease the delay between instructions, since drum rotation needed to be accounted for or else you might need to wait for nearly a full rotation to fetch each "next" instruction in sequence.

  5. #45
    PowerPoster
    Join Date
    Jul 2010
    Location
    NYC
    Posts
    3,236

    Re: VB.Variant vs C#.Object

    Quote Originally Posted by Elroy View Post
    To my way of thinking, a Variant is an intrinsic type (but I suppose that depends on your definition of "intrinsic type"). It's certainly not an object, other than the fact that it might contain a pointer to an object. A Variant has no vTable nor reference counter nor methods. It's just a 16 byte "thing", with the first two bytes being an integer code that specifies what the remaining 14 bytes are. And the remaining 14 bytes (or a portion thereof) are the actual data (or a pointer to the data in the case of strings, arrays, and objects).

    In other words, there's nothing fancy about Variants. They're just, occasionally very useful, 16 byte "flexible" variables. In my experience, they're quite fast. Compared to an explicitly typed variable, they just have the minor overhead of looking up their "type" and then applying all the typical rules for using that "type" (which any/all variables have).

    Also, you'd be shocked at how many of the input arguments to the VB6 language's functions are actually Variants. If we just started out with Variants, we'd save all that type conversion (to Variant) when calling all the VB6 functions. (But I'm definitely not recommending that.)
    I believe Elroy knows this but for anyone who doesn't; there's Variant versions and explicitly typed versions for many of these, like Left, or Mid. They're distinguished by the variable type symbol.... If you use Left(string, #), that's expecting a Variant and will do a type conversion to a Variant and then potentially back. But if you use Left$(string, #), that's explicitly typed for a String, and no type conversion is performed. You can see this in the Object Browser, where 2 different functions are listed:

    Function Left(String, Length As Long)
    Function Left$(String As String, Length As Long) As String

    Function ChrW(CharCode As Long)
    Function ChrW$(CharCode As Long) As String

    Function LCase(String)
    Function LCase$(String As String) As String

  6. #46
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    7,378

    Re: [RESOLVED] VB.Variant vs C#.Object

    Quote Originally Posted by Shaggy Hiker View Post
    I thought you might have been covering it that way, but I do feel the jump is more fundamental than the program counter. The program counter is one way to manage sequence, and it's the way most commonly used, but jump is required whether or not program counters are the mechanism used to manage sequence.

    Still, it's just a matter of view. If the program counter is used as an abstract concept, then, yeah, it is interchangeable with jump. The underlying concept is that you must have a means to designate the next action taken.
    Well when you think about it, a jump is defined in terms of the program counter. A statement like jump to address 0x56fcab10 is exactly the same as saying set the program counter to 0x56fcab10.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  7. #47
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    7,633

    Re: [RESOLVED] VB.Variant vs C#.Object

    Quote Originally Posted by fafalone View Post
    I believe Elroy knows this but for anyone who doesn't; there's Variant versions and explicitly typed versions for many of these, like Left, or Mid. They're distinguished by the variable type symbol.... If you use Left(string, #), that's expecting a Variant and will do a type conversion to a Variant and then potentially back. But if you use Left$(string, #), that's explicitly typed for a String, and no type conversion is performed. You can see this in the Object Browser, where 2 different functions are listed:

    Function Left(String, Length As Long)
    Function Left$(String As String, Length As Long) As String

    Function ChrW(CharCode As Long)
    Function ChrW$(CharCode As Long) As String

    Function LCase(String)
    Function LCase$(String As String) As String
    Yes, I was quite aware of those distinctions. However, many VB6 functions just say "number" or "expression" for their input arguments. And, when tested, they work equally well with a variety of input types. It's difficult to say with certainty without some disassembly, but I always assumed that pretty much all of those went in converted to Variants, and then were possibly further validated inside the intrinsic procedure.

    ADDED:
    Let's take Int() as a trivial example. In its case, it appears to even attempt to preserve the output type (put into a Variant):

    Code:
    Option Explicit
    
    Private Sub Form_Load()
        Dim n As Single
        Dim d As Double
        n = 123.45
        d = 678.91
        Debug.Print TypeName(Int(n)) ' Shows "Single"
        Debug.Print TypeName(Int(d)) ' Shows "Double"
    End Sub
    Last edited by Elroy; May 14th, 2022 at 08:55 AM.
    Any software I post in these forums written by me is provided “AS IS” without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that I’ve been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a “VB6 random code folder” that is overflowing. I’ve been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  8. #48
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    7,378

    Re: [RESOLVED] VB.Variant vs C#.Object

    Int is a function. Fully qualified it's actually VBA.Int. It takes a Variant and returns a Variant. TypeName cannot distinguish between type T and a Variant of type T.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  9. #49
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,813

    Re: [RESOLVED] VB.Variant vs C#.Object

    Quote Originally Posted by Niya View Post
    Int is a function. Fully qualified it's actually VBA.Int.
    Btw, this is the biggest lie the compiler makes you believe in. Int is an intrinsic and has nothing to with VBA.Int as its implemented as a direct call to runtime impl (one or several exports of MSVBVM60, one of the __vbaInt exports figuratively speaking). Many languages need such runtime support i.e. multiplying __int64 in C/C++ on a 32-compiler calls into a runtime function.

    Shift+F2 (Go to definition) lies and open object browser in VBA.Int but this is a travesty. This is not what get's called *unless* you use VBA.Int i.e. explicitly prefix with lib name.

    cheers,
    </wqw>

  10. #50
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    7,378

    Re: [RESOLVED] VB.Variant vs C#.Object

    Quote Originally Posted by wqweto View Post
    Btw, this is the biggest lie the compiler makes you believe in. Int is an intrinsic and has nothing to with VBA.Int as its implemented as a direct call to runtime impl (one or several exports of MSVBVM60, one of the __vbaInt exports figuratively speaking). Many languages need such runtime support i.e. multiplying __int64 in C/C++ on a 32-compiler calls into a runtime function.

    Shift+F2 (Go to definition) lies and open object browser in VBA.Int but this is a travesty. This is not what get's called *unless* you use VBA.Int i.e. explicitly prefix with lib name.

    cheers,
    </wqw>
    Wow I did not know this at all.

    I can't find anything on __vbaInt through Google. What is it's signature? I'm curious about it's return type and the type of it's parameter.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  11. #51
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,813

    Re: [RESOLVED] VB.Variant vs C#.Object

    Quote Originally Posted by Niya View Post
    I'm curious about it's return type and the type of it's parameter.
    This is the point of the compiler "hijacking" certain functions -- it can codegen more optimal implementation based on parameters/expected result data-types so no Variant conversion happens at all.

    This code

    Code:
    Private Sub Form_Click()
        Dim l As Long
        Dim n As Single
        Dim d As Double
        l = 456
        n = 123.45
        d = 678.91
        Print Int(l)
        Print Int(n)
        Print Int(d)
    End Sub
    . . .compiles to this

    Code:
    Private Sub Form_Click()
    00401914 55                   push        ebp  
    00401915 8B EC                mov         ebp,esp  
    00401917 83 EC 0C             sub         esp,0Ch  
    0040191A 68 C6 10 40 00       push        offset ___vbaExceptHandler (4010C6h)  
    0040191F 64 A1 00 00 00 00    mov         eax,dword ptr fs:[00000000h]  
    00401925 50                   push        eax  
    00401926 64 89 25 00 00 00 00 mov         dword ptr fs:[0],esp  
    0040192D 6A 18                push        18h  
    0040192F 58                   pop         eax  
    00401930 E8 8B F7 FF FF       call        VB@TEXT (4010C0h)  
    00401935 53                   push        ebx  
    00401936 56                   push        esi  
    00401937 57                   push        edi  
    00401938 89 65 F4             mov         dword ptr [ebp-0Ch],esp  
    0040193B C7 45 F8 B0 10 40 00 mov         dword ptr [ebp-8],offset __real@4@4005f6e6660000000000+8 (4010B0h)  
    00401942 8B 45 08             mov         eax,dword ptr [Me]  
    00401945 83 E0 01             and         eax,1  
    00401948 89 45 FC             mov         dword ptr [ebp-4],eax  
    0040194B 8B 45 08             mov         eax,dword ptr [Me]  
    0040194E 24 FE                and         al,0FEh  
    00401950 89 45 08             mov         dword ptr [Me],eax  
    00401953 8B 45 08             mov         eax,dword ptr [Me]  
    00401956 8B 00                mov         eax,dword ptr [eax]  
    00401958 FF 75 08             push        dword ptr [Me]  
    0040195B FF 50 04             call        dword ptr [eax+4]  
        Dim l As Long
        Dim n As Single
        Dim d As Double
        l = 456
    0040195E C7 45 E8 C8 01 00 00 mov         dword ptr [l],1C8h  
        n = 123.45
    00401965 D9 05 A8 10 40 00    fld         dword ptr [__real@4@4005f6e6660000000000 (4010A8h)]  
    0040196B D9 5D E4             fstp        dword ptr [n]  
        d = 678.91
    0040196E DD 05 A0 10 40 00    fld         qword ptr [__real@8@4008a9ba3d70a3d70800 (4010A0h)]  
    00401974 DD 5D DC             fstp        qword ptr [d]  
        Print Int(l)
    00401977 FF 75 E8             push        dword ptr [l]  
    0040197A FF 75 08             push        dword ptr [Me]  
    0040197D 68 10 16 40 00       push        offset ___vba@07C6D058 (401610h)  
    00401982 E8 CF F7 FF FF       call        ___vbaPrintObj (401156h)  
    00401987 83 C4 0C             add         esp,0Ch  
        Print Int(n)
    0040198A D9 45 E4             fld         dword ptr [n]  
    0040198D E8 BE F7 FF FF       call        @__vbaFPInt (401150h)  
    00401992 51                   push        ecx  
    00401993 D9 1C 24             fstp        dword ptr [esp]  
    00401996 FF 75 08             push        dword ptr [Me]  
    00401999 68 18 16 40 00       push        offset ___vba@07C6D064 (401618h)  
    0040199E E8 B3 F7 FF FF       call        ___vbaPrintObj (401156h)  
    004019A3 83 C4 0C             add         esp,0Ch  
        Print Int(d)
    004019A6 DD 45 DC             fld         qword ptr [d]  
    004019A9 E8 A2 F7 FF FF       call        @__vbaFPInt (401150h)  
    004019AE 51                   push        ecx  
    004019AF 51                   push        ecx  
    004019B0 DD 1C 24             fstp        qword ptr [esp]  
    004019B3 FF 75 08             push        dword ptr [Me]  
    004019B6 68 20 16 40 00       push        offset ___vba@07C6D070 (401620h)  
    004019BB E8 96 F7 FF FF       call        ___vbaPrintObj (401156h)  
    004019C0 83 C4 10             add         esp,10h  
    End Sub
    004019C3 C7 45 FC 00 00 00 00 mov         dword ptr [ebp-4],0  
    $L25:
    004019CA 8B 45 08             mov         eax,dword ptr [Me]  
    004019CD 8B 00                mov         eax,dword ptr [eax]  
    004019CF FF 75 08             push        dword ptr [Me]  
    004019D2 FF 50 08             call        dword ptr [eax+8]  
    004019D5 8B 45 FC             mov         eax,dword ptr [ebp-4]  
    004019D8 8B 4D EC             mov         ecx,dword ptr [ebp-14h]  
    004019DB 64 89 0D 00 00 00 00 mov         dword ptr fs:[0],ecx  
    004019E2 5F                   pop         edi  
    004019E3 5E                   pop         esi  
    004019E4 5B                   pop         ebx  
    004019E5 C9                   leave  
    004019E6 C2 04 00             ret         4
    So Int of Long is a noop (completely removed from codegen) and Int of Single/Double uses __vbaFPInt

    cheers,
    </wqw>

  12. #52
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    7,378

    Re: [RESOLVED] VB.Variant vs C#.Object

    Quote Originally Posted by wqweto View Post
    This is the point of the compiler "hijacking" certain functions -- it can codegen more optimal implementation based on parameters/expected result data-types so no Variant conversion happens at all.
    Ah. I see now. It seems that these runtime functions are specifically optimized to be embedded by the compiler. I could not help but notice this:-
    Code:
    ;    Print Int(n)
    
    fld dword ptr [n]  
    
    call @__vbaFPInt (401150h)  
    
    push ecx  
    
    fstp dword ptr [esp]
    __vbaFPInt doesn't even use a normal calling convention. The above code implies that it reads the floating point number directly from the x87 FPU stack, performs the conversion and places it right back on the FPU stack. Because it doesn't have the extra baggage that comes with normal calling conventions it would be much faster than calling a "real" function. It makes perfect sense.

    Do you know if CInt, CLng, CStr etc also work this way?
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  13. #53
    PowerPoster wqweto's Avatar
    Join Date
    May 2011
    Posts
    3,813

    Re: [RESOLVED] VB.Variant vs C#.Object

    Quote Originally Posted by Niya View Post
    Do you know if CInt, CLng, CStr etc also work this way?
    I'm positive they do.

    There are subtle differences with intrinsics though e.g. you cannot do CLng(AddressOf MyProc) while VBA.CLng(AddressOf MyProc) compiles fine.

    Btw, in "normal" calling convention FP params/retval are on the FPU stack so __vbaFPInt must be callable from C/C++ just fine.

    cheers,
    </wqw>

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width