dcsimg
Results 1 to 23 of 23

Thread: [RESOLVED] Variable names: Variant vs Explicit-Class-Name

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Resolved [RESOLVED] Variable names: Variant vs Explicit-Class-Name

    I'd like to know which of the following codes is better(about efficiency, memory usage, readability). Thanks.

    Code:
    Private Sub PushState_01()
        Dim obj As Variant
        
        If m_sKey <> vbNullString Then
            Set obj = New cToken
            obj.Key = m_sKey
        Else
            Set obj = Nothing
        End If
        
        Set m_arrItem(m_nPointer) = obj
    End Sub
    Code:
    Private Sub PushState_02()
        Dim obj As cToken
        
        If m_sKey <> vbNullString Then
            Set obj = New cToken
            obj.Key = m_sKey
        End If
        
        Set m_arrItem(m_nPointer) = obj
    End Sub
    Added (according to dilettante's suggestion):
    Code:
        Dim obj As Object
        
        If m_sKey <> vbNullString Then
            Set obj = New cToken
            obj.Key = m_sKey
        End If
        
        Set m_arrItem(m_nPointer) = obj
    Last edited by dreammanor; May 22nd, 2019 at 08:38 AM.

  2. #2
    PowerPoster
    Join Date
    Feb 2006
    Posts
    20,534

    Re: Variable names: Variant vs Explicit-Class-Name

    You left out Object, not as efficient as strong typing but lighter-weight than a Variant.

  3. #3

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by dilettante View Post
    You left out Object, not as efficient as strong typing but lighter-weight than a Variant.
    Hi dilettante, thank you for your reply. Do you mean that strong typing is the most efficient? Also, does "strong typing" take up more memory in an array?

  4. #4
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,453

    Re: Variable names: Variant vs Explicit-Class-Name

    A variable is always going to take as much memory as it's going to need. No more, no less.

    A variant is going to need what ever memory it needs to hold what the value is, be it a boolean, a pointer, an integer, a long, or a complex class, plus, a little bit extra (two bytes if I remember right) to hold a value descriptor as to what it is holding. No more, no less.

    A strongly typed variable is going to need what ever memory it needs to hold the value is, be it a boolean, a pointer, an integer, a long, or a complex class. No more, no less.


    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  5. #5
    PowerPoster
    Join Date
    Feb 2006
    Posts
    20,534

    Re: Variable names: Variant vs Explicit-Class-Name

    A Variant's header is 8 bytes long.

  6. #6
    PowerPoster
    Join Date
    Feb 2006
    Posts
    20,534

    Re: Variable names: Variant vs Explicit-Class-Name

    Since you are storing objects, both an Object typed value and a strongly-typed value are an object instance reference and take a DWORD (4 bytes). Using a Variant adds the header overhead to that.

  7. #7

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by techgnome View Post
    A variable is always going to take as much memory as it's going to need. No more, no less.

    A variant is going to need what ever memory it needs to hold what the value is, be it a boolean, a pointer, an integer, a long, or a complex class, plus, a little bit extra (two bytes if I remember right) to hold a value descriptor as to what it is holding. No more, no less.

    A strongly typed variable is going to need what ever memory it needs to hold the value is, be it a boolean, a pointer, an integer, a long, or a complex class. No more, no less.


    -tg
    Hi techgnome, thank you for your reply. In fact, I want to compare the efficiency and memory usage of Variant, Object, and Strong Typing (Explicit-Class-Name) when the object is Nothing (not instantiated).

  8. #8

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by dilettante View Post
    A Variant's header is 8 bytes long.
    Quote Originally Posted by dilettante View Post
    Since you are storing objects, both an Object typed value and a strongly-typed value are an object instance reference and take a DWORD (4 bytes). Using a Variant adds the header overhead to that.
    Hi dilettante, can I understand this: after the class is instantiated, an Object typed value and a strongly-typed value take up less memory than a variant typed value?

    So, if the class is not instantiated, what is the result? Because I want to compare the efficiency and memory usage of Variant, Object, and Strong Typing (Explicit-Class-Name) when the object is Nothing (not instantiated).

  9. #9
    PowerPoster
    Join Date
    Feb 2006
    Posts
    20,534

    Re: Variable names: Variant vs Explicit-Class-Name

    When an object reference variable has been set = Nothing, such as when it is new, it takes up one DWORD or 4 bytes.

    Once you assign it an instance of an object any of them get an object reference as their value. The instance itself takes up space too of course.

    A Variant always takes up 16 bytes, no matter what you store in it. Some types are stored inline, some types store a pointer to the actual value. They hold a header and a value and the value can be 8 bytes or if less then there are unused padding bytes.

    As it says in the manual:

    Note A variant always takes up 16 bytes, no matter what you store in it. Objects, strings, and arrays are not physically stored in the Variant; in these cases, four bytes of the Variant are used to hold either an object reference, or a pointer to the string or array. The actual data are stored elsewhere.

  10. #10
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    34,090

    Re: Variable names: Variant vs Explicit-Class-Name

    Why are you asking? After all, memory management is a pretty complex subject that has a fair amount to do with the hardware you are running the code on. For example, if all your data is sitting out in RAM, then it would be more efficient if that data was in the CPU cache. The OS may well load your data into the CPU cache, but it isn't going to go out and get one byte on one trip and another byte on another trip. That wouldn't be efficient. Instead, it will likely bring some large size page into cache memory even if it really only needs one byte from that page. At that point, does it really matter how many bytes your data is taking? If the hardware is moving 4KB pages in and out of CPU cache memory, why care whether your object takes 2 bytes or 8? Most likely, it would be faster to obtain 8 bytes from the CPU cache than it would be to obtain 2 bytes from RAM, and certainly faster than it would be to obtain 2 bytes from a hard drive.

    Furthermore, some memory manipulations are more efficient if they are on some boundary, which has changed over time and I have no idea how it currently works. At one point, you'd be more efficient getting items that were at 4 or 8 byte boundaries (I don't remember the details) in memory, so even if you only needed one byte, you'd waste the rest to get better performance. That's roughly how cache memory works now: When you need something, move the most efficient amount around rather than just what you need. Memory is cheap, time is money.

    So, efficiency and compactness do not always go together. You may well trade size for efficiency, and that's a reasonable trade these days. Size mostly matters for CPU activities, and that's a whole different matter, since CPU registers aren't going to hold an object anyways. Unless you are working with some kind of embedded system where every byte counts, this really isn't an issue worth wasting your time over. The hardware will pad out your object to whatever is efficient for the hardware, and you shouldn't bother with that, since it will do a better job. The extreme example of that is the Boolean, which technically requires one bit, but since the hardware can't address less than a byte, then a Boolean has to take a minimum of eight times the size it technically requires (or you could pack 8 Booleans into a byte), but since no modern CPU will work efficiently with a single byte, that Boolean is sure to require moving around some larger number of bytes to access it. Those extra bytes may hold more data, or they may be wasted space simply because wasting the space can be more efficient than spending the time to pack data into it. This can happen at the CPU to cache level, as well as at the cache to RAM level and the RAM to fixed storage level.

    The bottom line is: Don't worry about data size unless you have a specific reason to worry about data size. In all other cases, execution performance is more important, and that may well mean wasting space.
    My usual boring signature: Nothing

  11. #11
    Frenzied Member
    Join Date
    Feb 2017
    Posts
    1,835

    Re: Variable names: Variant vs Explicit-Class-Name

    dreammanor, if speed is important, then use strong typing since it uses early binding. No doubt.

  12. #12
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    5,696

    Re: Variable names: Variant vs Explicit-Class-Name

    Ok, I'll weigh in on this one.

    First, a variant is always 16 bytes, and it only has a two byte header, which defines the Variant type. Now, if you explore that Wikipedia page, don't start going crazy thinking you can use all those types in VB6. You can't. The only type I've found that can be used that isn't explicitly mentioned in VB6's MSDN is the LongLong.

    So, what are the other 14 bytes for? Well, let's talk a bit more about those first two bytes first. One of the bits (&H4000) in that two bytes is a ByRef flag. Typically, a variant is considered ByVal. (And don't confuse this with how arguments are passed. We can pass a ByRef Variant as ByVal, or vice-versa. It's the same concept but used in a different context.)

    So, we'll start with the ByVal type Variants. In these, we can put Bytes, Integers, Longs, Singles, Doubles, Decimals, Currency, Dates, and a couple others (such as LongLong). They go in that extra 14 bytes. Now, above, Dil said the header is 8 bytes long, but that's not correct. All there is to it is that 2 bytes. A Decimal type (which, for VB6, only exists in a Variant) uses all 14 of the remaining bytes. In all other cases, they're just unused. (Also, it's rare, but those numeric types can actually be ByRef in a Variant.)

    So, to get to the case-at-hand ... an object in a Variant. Because of the way Variants are declared, they're always late-bound, similar to declaring an object variable As Object (or any other way that's not specific to a specific class name, such as As Control). (To allow a Variant to be early-bound, we would quickly run out of options in our two byte header. And actually, Microsoft reserves all the unused ones for future things they may want to put into a Variant.)

    So, dreammanor, let's clear up a hierarchy that you (sort of) outlined:

    Code:
    Dim oSpecific As MyClassName
    Dim oGeneral As Object
    Dim v As Variant

    For the first, the object always knows its class, and it can be instantiated/uninstantiated the fastest, because much less "look-up" is involved, and the compiler can be smarter about it.

    For the second, when instantiating some object into that oGeneral, a "look-up" must be performed to figure how what type of object it is, which isn't as "clean" as the first.

    For the third, we've also got the bit of extra overhead to figure out that the Variant is an object (VT_DISPATCH (9) set in the first two bytes), and then, it's got to figure out the late-binding (same as the second case). Or, in the case of instantiating the object, it has to set VT_DISPATCH into the first two bytes of the Variant.

    So, just to say a bit more about Variants. When you put things like Strings (BSTR) or Objects into Variants, they are implicitly ByRef. It's never assumed that the entire String or object instantiation could fit into the Variant's 14 data bytes. Therefore, only a pointer-address is placed into the Variant's data (similar to a Long, but it's a pointer). Now, even though these are ByRef, that Variant ByRef flag isn't set (but I don't think it would matter if it was (but not tested)). This is all quite similar to any object variable (early or late bound), but just with an extra bit of Variant Type overhead.

    You're certainly welcome to do speed-tests on all three approaches. Truth be told, I'd be surprised if there's much difference between "As Object" and "As Variant".

    Hope That Helps,
    Elroy
    Last edited by Elroy; May 22nd, 2019 at 03:45 PM.
    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.

  13. #13
    PowerPoster
    Join Date
    Feb 2006
    Posts
    20,534

    Re: Variable names: Variant vs Explicit-Class-Name

    It would be simpler if he'd just look up the tagVARIANT/VARIANT struct himself. The only complicated case is the ByVal Decimal which feels like it was an afterthought.

  14. #14

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by dilettante View Post
    When an object reference variable has been set = Nothing, such as when it is new, it takes up one DWORD or 4 bytes.

    Once you assign it an instance of an object any of them get an object reference as their value. The instance itself takes up space too of course.

    A Variant always takes up 16 bytes, no matter what you store in it. Some types are stored inline, some types store a pointer to the actual value. They hold a header and a value and the value can be 8 bytes or if less then there are unused padding bytes.

    As it says in the manual:
    I see, thank you dil.

    Quote Originally Posted by Eduardo- View Post
    dreammanor, if speed is important, then use strong typing since it uses early binding. No doubt.
    Thank you, Eduardo

  15. #15

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by Elroy View Post
    Ok, I'll weigh in on this one.

    First, a variant is always 16 bytes, and it only has a two byte header, which defines the Variant type. Now, if you explore that Wikipedia page, don't start going crazy thinking you can use all those types in VB6. You can't. The only type I've found that can be used that isn't explicitly mentioned in VB6's MSDN is the LongLong.

    So, what are the other 14 bytes for? Well, let's talk a bit more about those first two bytes first. One of the bits (&H4000) in that two bytes is a ByRef flag. Typically, a variant is considered ByVal. (And don't confuse this with how arguments are passed. We can pass a ByRef Variant as ByVal, or vice-versa. It's the same concept but used in a different context.)

    So, we'll start with the ByVal type Variants. In these, we can put Bytes, Integers, Longs, Singles, Doubles, Decimals, Currency, Dates, and a couple others (such as LongLong). They go in that extra 14 bytes. Now, above, Dil said the header is 8 bytes long, but that's not correct. All there is to it is that 2 bytes. A Decimal type (which, for VB6, only exists in a Variant) uses all 14 of the remaining bytes. In all other cases, they're just unused. (Also, it's rare, but those numeric types can actually be ByRef in a Variant.)

    So, to get to the case-at-hand ... an object in a Variant. Because of the way Variants are declared, they're always late-bound, similar to declaring an object variable As Object (or any other way that's not specific to a specific class name, such as As Control). (To allow a Variant to be early-bound, we would quickly run out of options in our two byte header. And actually, Microsoft reserves all the unused ones for future things they may want to put into a Variant.)

    So, dreammanor, let's clear up a hierarchy that you (sort of) outlined:

    Code:
    Dim oSpecific As MyClassName
    Dim oGeneral As Object
    Dim v As Variant

    For the first, the object always knows its class, and it can be instantiated/uninstantiated the fastest, because much less "look-up" is involved, and the compiler can be smarter about it.

    For the second, when instantiating some object into that oGeneral, a "look-up" must be performed to figure how what type of object it is, which isn't as "clean" as the first.

    For the third, we've also got the bit of extra overhead to figure out that the Variant is an object (VT_DISPATCH (9) set in the first two bytes), and then, it's got to figure out the late-binding (same as the second case). Or, in the case of instantiating the object, it has to set VT_DISPATCH into the first two bytes of the Variant.

    So, just to say a bit more about Variants. When you put things like Strings (BSTR) or Objects into Variants, they are implicitly ByRef. It's never assumed that the entire String or object instantiation could fit into the Variant's 14 data bytes. Therefore, only a pointer-address is placed into the Variant's data (similar to a Long, but it's a pointer). Now, even though these are ByRef, that Variant ByRef flag isn't set (but I don't think it would matter if it was (but not tested)). This is all quite similar to any object variable (early or late bound), but just with an extra bit of Variant Type overhead.

    You're certainly welcome to do speed-tests on all three approaches. Truth be told, I'd be surprised if there's much difference between "As Object" and "As Variant".

    Hope That Helps,
    Elroy
    Very detailed explanation, thank you, Elroy.

  16. #16

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by Shaggy Hiker View Post
    Why are you asking? After all, memory management is a pretty complex subject that has a fair amount to do with the hardware you are running the code on. For example, if all your data is sitting out in RAM, then it would be more efficient if that data was in the CPU cache. The OS may well load your data into the CPU cache, but it isn't going to go out and get one byte on one trip and another byte on another trip. That wouldn't be efficient. Instead, it will likely bring some large size page into cache memory even if it really only needs one byte from that page. At that point, does it really matter how many bytes your data is taking? If the hardware is moving 4KB pages in and out of CPU cache memory, why care whether your object takes 2 bytes or 8? Most likely, it would be faster to obtain 8 bytes from the CPU cache than it would be to obtain 2 bytes from RAM, and certainly faster than it would be to obtain 2 bytes from a hard drive.

    Furthermore, some memory manipulations are more efficient if they are on some boundary, which has changed over time and I have no idea how it currently works. At one point, you'd be more efficient getting items that were at 4 or 8 byte boundaries (I don't remember the details) in memory, so even if you only needed one byte, you'd waste the rest to get better performance. That's roughly how cache memory works now: When you need something, move the most efficient amount around rather than just what you need. Memory is cheap, time is money.

    So, efficiency and compactness do not always go together. You may well trade size for efficiency, and that's a reasonable trade these days. Size mostly matters for CPU activities, and that's a whole different matter, since CPU registers aren't going to hold an object anyways. Unless you are working with some kind of embedded system where every byte counts, this really isn't an issue worth wasting your time over. The hardware will pad out your object to whatever is efficient for the hardware, and you shouldn't bother with that, since it will do a better job. The extreme example of that is the Boolean, which technically requires one bit, but since the hardware can't address less than a byte, then a Boolean has to take a minimum of eight times the size it technically requires (or you could pack 8 Booleans into a byte), but since no modern CPU will work efficiently with a single byte, that Boolean is sure to require moving around some larger number of bytes to access it. Those extra bytes may hold more data, or they may be wasted space simply because wasting the space can be more efficient than spending the time to pack data into it. This can happen at the CPU to cache level, as well as at the cache to RAM level and the RAM to fixed storage level.

    The bottom line is: Don't worry about data size unless you have a specific reason to worry about data size. In all other cases, execution performance is more important, and that may well mean wasting space.
    Thank you Shaggy Hiker. It is said that VSCode can smoothly read a file with 3 million lines of code, and my code editor can only read 500,000 lines of code files (after that, computer memory is exhausted). So I want to minimize memory usage and improve the reading speed of code files.

    If the program written in VB6 is slower than the one written in TypeScript, I'd be extremely ashamed.

  17. #17
    Frenzied Member wqweto's Avatar
    Join Date
    May 2011
    Posts
    1,547

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by Elroy View Post
    Now, even though these are ByRef, that Variant ByRef flag isn't set (but I don't think it would matter if it was (but not tested)).
    VT_BYREF flag adds *second* indirection for more bizzare use-cases.

    When you have a sText As String as a local variable the BSTR sText is a 4-byte pointer (i.e. 1-st indirection to actual string characters). When you pass sText to a function with a ByRef vText As Variant parameter you get a VT_BYREF | VT_BSTR variant with a pointer to sText i.e. second indirection. To get to the actual characters you first dereference *vData.pbstrVal to a BSTR and then dereference this pointer for the actual data.

    So in our function setting vText = "new one" is able to modify the caller variable (if the argument is an actual variable a not a compiler generated temporary). This means that something like Set vText = New Collection will *fail* as this object cannot be cast to a BSTR! WТF?!@

    It turns out you first have to assign vText = Empty to clear the VT_BYREF flag so that latter assignment no longer tries to modify caller's variable and fail w/ incompatibility in the meantime.

    cheers,
    </wqw>

  18. #18
    PowerPoster
    Join Date
    Feb 2006
    Posts
    20,534

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by dreammanor View Post
    If the program written in VB6 is slower than the one written in TypeScript, I'd be extremely ashamed.
    VSCode is a riff on the Atom editor. It automates some adaptation of Electron, where the "code" is basically macro logic invoking optimized native code that was originally designed to underlie text editing tools.

    It's like giving a bag of Word VBA macros the credit for Word's capabilities and strengths. The power is not in TypeScript which can only crap out JavaScript. The power is in the thing automated via the JavaScript macro logic.

  19. #19

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by wqweto View Post
    VT_BYREF flag adds *second* indirection for more bizzare use-cases.

    When you have a sText As String as a local variable the BSTR sText is a 4-byte pointer (i.e. 1-st indirection to actual string characters). When you pass sText to a function with a ByRef vText As Variant parameter you get a VT_BYREF | VT_BSTR variant with a pointer to sText i.e. second indirection. To get to the actual characters you first dereference *vData.pbstrVal to a BSTR and then dereference this pointer for the actual data.

    So in our function setting vText = "new one" is able to modify the caller variable (if the argument is an actual variable a not a compiler generated temporary). This means that something like Set vText = New Collection will *fail* as this object cannot be cast to a BSTR! WТF?!@

    It turns out you first have to assign vText = Empty to clear the VT_BYREF flag so that latter assignment no longer tries to modify caller's variable and fail w/ incompatibility in the meantime.

    cheers,
    </wqw>
    Thank you for your supplement, wqweto.

  20. #20

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by dilettante View Post
    VSCode is a riff on the Atom editor. It automates some adaptation of Electron, where the "code" is basically macro logic invoking optimized native code that was originally designed to underlie text editing tools.

    It's like giving a bag of Word VBA macros the credit for Word's capabilities and strengths. The power is not in TypeScript which can only crap out JavaScript. The power is in the thing automated via the JavaScript macro logic.
    Yes. I hope my program is much faster than a JavaScript native program (such as VSCode). I know that V8 can interpret JavaScript as native bytecode, but I still don't believe JavaScript and V8 is faster than VB6.

  21. #21
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    5,696

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by wqweto View Post
    VT_BYREF flag adds *second* indirection for more bizzare use-cases.

    When you have a sText As String as a local variable the BSTR sText is a 4-byte pointer (i.e. 1-st indirection to actual string characters). When you pass sText to a function with a ByRef vText As Variant parameter you get a VT_BYREF | VT_BSTR variant with a pointer to sText i.e. second indirection. To get to the actual characters you first dereference *vData.pbstrVal to a BSTR and then dereference this pointer for the actual data.

    So in our function setting vText = "new one" is able to modify the caller variable (if the argument is an actual variable a not a compiler generated temporary). This means that something like Set vText = New Collection will *fail* as this object cannot be cast to a BSTR! WТF?!@

    It turns out you first have to assign vText = Empty to clear the VT_BYREF flag so that latter assignment no longer tries to modify caller's variable and fail w/ incompatibility in the meantime.

    cheers,
    </wqw>
    Interesting. I should have expected some such. I knew that things like numbers could use the Variant's ByVal/ByRef flag. However, I wasn't sure how a String or Object would use it. It does make sense though that it adds another level that requires de-referencing. Thanks for the explanation.

    So dreammanor ... none of this should matter to what you're examining. I was possibly just getting a bit too detailed on how Variants work, and wqweto cleared something up on a rather esoteric point.

    Regarding Variants, I remember when I used to avoid them like the plague. I still only use them when it's appropriate, preferring to declare a variable more specifically. However, I'm no longer "afraid" of them. And, once you understand them, they're really quite simplistic, a 2-byte "type" header followed by 14 bytes for data (which may be actual data or a pointer to additional data). And in most cases, much of that 14 bytes goes unused.

    When dealing with Collections (with the data-piece of each item being a Variant), they come in quite handy.

    Y'all Take Care,
    Elroy
    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.

  22. #22

    Thread Starter
    Frenzied Member
    Join Date
    Sep 2012
    Posts
    1,608

    Re: Variable names: Variant vs Explicit-Class-Name

    Quote Originally Posted by Elroy View Post
    Interesting. I should have expected some such. I knew that things like numbers could use the Variant's ByVal/ByRef flag. However, I wasn't sure how a String or Object would use it. It does make sense though that it adds another level that requires de-referencing. Thanks for the explanation.

    So dreammanor ... none of this should matter to what you're examining. I was possibly just getting a bit too detailed on how Variants work, and wqweto cleared something up on a rather esoteric point.

    Regarding Variants, I remember when I used to avoid them like the plague. I still only use them when it's appropriate, preferring to declare a variable more specifically. However, I'm no longer "afraid" of them. And, once you understand them, they're really quite simplistic, a 2-byte "type" header followed by 14 bytes for data (which may be actual data or a pointer to additional data). And in most cases, much of that 14 bytes goes unused.

    When dealing with Collections (with the data-piece of each item being a Variant), they come in quite handy.

    Y'all Take Care,
    Elroy
    Any useful knowledge is welcome, thank you Elroy, thank you wqweto.

  23. #23
    Frenzied Member
    Join Date
    Feb 2017
    Posts
    1,835

    Re: [RESOLVED] Variable names: Variant vs Explicit-Class-Name

    The title of the thread is wrong: it is not about variable names but about variable types.

Posting Permissions

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



Featured


Click Here to Expand Forum to Full Width