Re: Error Raising and Memory in VB (general question)

From: Vlad Kozin (VladKozin_at_hotmail.com)
Date: 02/14/04 

Date: Sat, 14 Feb 2004 00:32:13 GMT

Hi Mark,

"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message

> > What I was told about VB6, it normally releases all allocated memory
> > on program exit only.
>
> If you have an object variable allocated on the stack, and it goes out of
> scope - for any reason, including errors - the object terminates and the
> memory is released. Likewise, any class-level variables that exist when
the
> object is terminated go out of scope, and the memory is also released.
What
> you have probably been told must refer to all module-level object
variables,
> and global references.
>

In general, I agree with you.
But why are you saying it uses stack? I know that was true for 16-bit apps
that if you call a function it's supposed to push the function parameters to
the stack, then call the function, etc...

I think we are dealing with heap memory here. A process in NT-family
environment is assigned a process-level heap. All BSTR type strings (read:
VB strings) are allocated on the process heap.
MSDN says:
"COM's IMalloc allocator (or CoTaskMemAlloc / CoTaskMemFree): Functions use
the default per-process heap. Automation uses the Component Object Model
(COM)'s allocator, and the requests use the per-process heap."
So I guess when we call COM or Automation (ActiveX) objects, we use the heap
memory.
When we do Set myobj = New clsObject, the OS allocates a part of the heap
space for the object instance.
I tried to search MSDN for the stack use in VB, and I didn't find any
mentioning of it...

> > So if your program is supposed to run or stay in memory for some
> > time, or it calls a function in a loop, make sure you correctly set
> > all object references to Nothing within your program, or function.
>
> You almost never have to explicitly *have to* set object variables to
> nothing. And you *never* have to do that with object variables allocated
on
> the stack, because the VB compiler automatically adds explicit Set =
Nothing
> at the end of procedures - as well as in Terminate events.

I believe you, but I would not state that, unless I am a MS developer who
actually designed or wrote the VB6 compiler (or, to be precise, MSVC++ 1.0
compiler)...

> > If your VB program calls any WinAPI functions (including those like
> > FindFirstFile, etc.) do not rely on the VB runtime to release memory
> > or to close the file handles for you. Do it yourself.
>
> I would completely agree with this. This is why the Terminate event is so
> damn useful.
>

Thank you :)

> --
> Mark Bertenshaw
> Kingston upon Thames
> UK
>

regards,
Vlad

Relevant Pages

  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (comp.lang.cpp)
  • Re: ten thousand small processes
    ... "stack and data have different VM protections and, ... >> writing a general purpose malloc is significantly more complicated, ... Calling mallocfor the first time causes a 16K spike in memory usage under ... are wonderful decisions for a memory allocator tuned for a very ...
    (freebsd-performance)
  • Re: Linked List & Dynamic Memory Allocation
    ... Both of you mentioned stack and heap in this ... when I call malloc it uses heap to allocate memory. ... if you have an integer pointer object that lives beyond this scope and you had: ...
    (microsoft.public.vc.mfc)
  • Re: Stack, Heap, Mfc
    ... >> is put on the heap. ... >> decendant does this not mean that all memory will be on the heap because ... > stack or the heap. ... You first try to limit the recursion to an acceptable ...
    (microsoft.public.vc.mfc)