-
Feb 22nd, 2021, 03:43 AM
#41
Re: Any technical reason not to use Call in VB6?
Originally Posted by Zvoni
IMO, the above code is going to leak, since i don't have any chance to destroy the new "class1"
Am i right?
Not exactly.
A new Class1 instance will be created with RefCount = 1 in Form_Load just before calling each MySub and this instance will get an IUnknown::Release call in Form_Load after each MySub call.
Only if this decreases the instance's RefCount to 0 will this instance self-terminate and deallocate it own memory. This is how COM works, the instance commits suicide with a delete this; (in C/C++ terms) in its own Release implementation.
If MySub stores its oParam in a global variable then IUnknown::Release call in Form_Load will not render RefCount to 0 so it will have no consequences for the passed in instance.
cheers,
</wqw>
-
Feb 22nd, 2021, 04:34 AM
#42
Re: Any technical reason not to use Call in VB6?
Originally Posted by Phill.W
Personally, I use Call because I also work with other languages where the the use of brackets is required.
It makes shifting from one language to another [slightly] less jarring.
This, exactly.
-
Feb 22nd, 2021, 04:39 AM
#43
Re: Any technical reason not to use Call in VB6?
Originally Posted by Elroy
I built this little function that I now use. I replaced all my "Call" statements with that little "Retn" procedure, all all for dilettante.
Thanks for raising this post from the dead, sometimes a little gem re-emerges.
Last edited by yereverluvinuncleber; Feb 22nd, 2021 at 05:12 AM.
-
Feb 22nd, 2021, 09:39 AM
#44
Re: Any technical reason not to use Call in VB6?
Since this thread is back..
My personal preference is to use the keyword "Call" when invoking a "Sub" method.
So I know while reading code if a function can return something or not. (We ignore just now that a Sub is actually a function which returns HRESULT..)
If the other function is not a "Sub", means it returns something I do not use the keyword "Call".
Most of the cases a returning function is used in an equation line ("=")
However, sometimes I invoke a function without saving the return value.
Examples:
Code:
Call MySub
MyFunction
-
Feb 22nd, 2021, 10:37 AM
#45
Re: Any technical reason not to use Call in VB6?
Originally Posted by Zvoni
I know that vb6 is cleaning up after you, but i know from other languages that you have to clean up after yourself.
For all intents and purposes: Imagine vb6 NOT cleaning up after you, would that code leak?
And i consider it "good" practice to destroy everything yourself, that you created (Set MyClass = Nothing)
If we are going to imagine a hypothetical language, then the answer is a definite maybe. It all depends on how we imagine that hypothetical language to behave. The class IS created, so there is memory allocated somewhere, and what happens when it goes out of scope depends on the hypothetical language. If the language created the object on the stack (does ANY language do that?), then it would go away. If the language is garbage collected, like .NET, then it will just reside out on the heap, perhaps for the life of the program. That's not a leak, it's just efficient. Recovering the memory is costly, so garbage collection won't happen unless it has to. I could imagine other approaches, as well.
Also, does setting the variable to Nothing really destroy anything?
My usual boring signature: Nothing
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|