Cleanup with Erase after Split?

[Michael \(michka\) Kaplan [MS]]

Re: Cleanup with Erase after Split?

The fact remains that it is not really a useful operation. COM does not work
in a way that sees a difference UNLESS you need to:

(a) deal with global variables which would not be freed up until you reset
code or exit the app, or

(b) want to free up the memory prior to the end of the proc when the
implicit freeing up would happen.


--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.


"Larry Linson" <bouncer@localh ost.not> wrote in message
news:M66Db.1046 6$xO.6586@nwrdd c02.gnilink.net ...[color=blue]
> "Tom van Stiphout" wrote
>[color=green]
> > I just did. Results: no noticeable
> > effects. Indeed VBA must be freeing
> > memory behind the scenes. You
> > were right all along.[/color]
>
> You don't suppose this might be one of those "it always does this (except
> when it doesn't)" cases?
>
> We've seen enough of those cases in various software, including Access,[/color]
over[color=blue]
> the years, that I consider it "not just superstition" to set objects to
> Nothing when I am finished with them.
>
> Larry Linson
> Microsoft Access MVP
>
>[/color]

[Larry Linson]

Re: Cleanup with Erase after Split?

"TC" wrote
[color=blue]
> But he is not talking of setting
> objects to nothing. (I do that
> myself). He is talking of Erase'ing
> arrays.[/color]

I didn't indicate he was. I just used it as an example of "it always works
that way, except when it doesn't".

[Larry Linson]

Re: Cleanup with Erase after Split?

Are you talking about Erasing?

Or do you mean that Access is now so good at handling resources now that I
no longer need to set objects to Nothing when I'm done with them. It's
always been _supposed_ to clean up when they go out of scope, but it hasn't
always done a great job of it.

Larry

"Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
message news:3fdcff8c$1 @news.microsoft .com...[color=blue]
> The fact remains that it is not really a useful operation. COM does not[/color]
work[color=blue]
> in a way that sees a difference UNLESS you need to:
>
> (a) deal with global variables which would not be freed up until you reset
> code or exit the app, or
>
> (b) want to free up the memory prior to the end of the proc when the
> implicit freeing up would happen.
>
>
> --
> MichKa [MS]
> NLS Collation/Locale/Keyboard Development
> Globalization Infrastructure and Font Technologies
>
> This posting is provided "AS IS" with
> no warranties, and confers no rights.
>
>
> "Larry Linson" <bouncer@localh ost.not> wrote in message
> news:M66Db.1046 6$xO.6586@nwrdd c02.gnilink.net ...[color=green]
> > "Tom van Stiphout" wrote
> >[color=darkred]
> > > I just did. Results: no noticeable
> > > effects. Indeed VBA must be freeing
> > > memory behind the scenes. You
> > > were right all along.[/color]
> >
> > You don't suppose this might be one of those "it always does this[/color][/color]
(except[color=blue][color=green]
> > when it doesn't)" cases?
> >
> > We've seen enough of those cases in various software, including Access,[/color]
> over[color=green]
> > the years, that I consider it "not just superstition" to set objects to
> > Nothing when I am finished with them.
> >
> > Larry Linson
> > Microsoft Access MVP
> >
> >[/color]
>
>[/color]

[Michael \(michka\) Kaplan [MS]]

Re: Cleanup with Erase after Split?

The advice applies to both, and I would challenge *anyone* to come up with
an example beyond the below two scenarios that require it. It has nothing
whatsoever to do with Access, it is how COM works.


--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.


"Larry Linson" <bouncer@localh ost.not> wrote in message
news:J4bDb.1534 7$gk1.6755@nwrd dc01.gnilink.ne t...[color=blue]
> Are you talking about Erasing?
>
> Or do you mean that Access is now so good at handling resources now that I
> no longer need to set objects to Nothing when I'm done with them. It's
> always been _supposed_ to clean up when they go out of scope, but it[/color]
hasn't[color=blue]
> always done a great job of it.
>
> Larry
>
> "Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
> message news:3fdcff8c$1 @news.microsoft .com...[color=green]
> > The fact remains that it is not really a useful operation. COM does not[/color]
> work[color=green]
> > in a way that sees a difference UNLESS you need to:
> >
> > (a) deal with global variables which would not be freed up until you[/color][/color]
reset[color=blue][color=green]
> > code or exit the app, or
> >
> > (b) want to free up the memory prior to the end of the proc when the
> > implicit freeing up would happen.
> >
> >
> > --
> > MichKa [MS]
> > NLS Collation/Locale/Keyboard Development
> > Globalization Infrastructure and Font Technologies
> >
> > This posting is provided "AS IS" with
> > no warranties, and confers no rights.
> >
> >
> > "Larry Linson" <bouncer@localh ost.not> wrote in message
> > news:M66Db.1046 6$xO.6586@nwrdd c02.gnilink.net ...[color=darkred]
> > > "Tom van Stiphout" wrote
> > >
> > > > I just did. Results: no noticeable
> > > > effects. Indeed VBA must be freeing
> > > > memory behind the scenes. You
> > > > were right all along.
> > >
> > > You don't suppose this might be one of those "it always does this[/color][/color]
> (except[color=green][color=darkred]
> > > when it doesn't)" cases?
> > >
> > > We've seen enough of those cases in various software, including[/color][/color][/color]
Access,[color=blue][color=green]
> > over[color=darkred]
> > > the years, that I consider it "not just superstition" to set objects[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > Nothing when I am finished with them.
> > >
> > > Larry Linson
> > > Microsoft Access MVP
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Larry Linson]

Re: Cleanup with Erase after Split?

Well, I'm glad to hear that they have fixed the "always releases the
object's memory and clears the reference when it goes out of scope, except
when it doesn't" phenomenon. As I recall, it was there, but not too bad in
Access 2.0, but was very significantly worse in Access 95, and not fixed in
Access 97. Given the other things that have been neglected, it is a real
surprise that they have paid attention to this one.

I'm not certain that I'm going to quit setting objects to nothing when I'm
done, though, even if that is right before they go out of scope -- it seems
quite orderly to "unset" something you have "set" just as it seems quite
reasonable to "close" something you have "opened".

Regards,

Larry Linson


"Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
message news:3fddb592@n ews.microsoft.c om...[color=blue]
> The advice applies to both, and I would challenge *anyone* to come up with
> an example beyond the below two scenarios that require it. It has nothing
> whatsoever to do with Access, it is how COM works.
>
>
> --
> MichKa [MS]
> NLS Collation/Locale/Keyboard Development
> Globalization Infrastructure and Font Technologies
>
> This posting is provided "AS IS" with
> no warranties, and confers no rights.
>
>
> "Larry Linson" <bouncer@localh ost.not> wrote in message
> news:J4bDb.1534 7$gk1.6755@nwrd dc01.gnilink.ne t...[color=green]
> > Are you talking about Erasing?
> >
> > Or do you mean that Access is now so good at handling resources now that[/color][/color]
I[color=blue][color=green]
> > no longer need to set objects to Nothing when I'm done with them. It's
> > always been _supposed_ to clean up when they go out of scope, but it[/color]
> hasn't[color=green]
> > always done a great job of it.
> >
> > Larry
> >
> > "Michael (michka) Kaplan [MS]" <michkap@online .microsoft.com> wrote in
> > message news:3fdcff8c$1 @news.microsoft .com...[color=darkred]
> > > The fact remains that it is not really a useful operation. COM does[/color][/color][/color]
not[color=blue][color=green]
> > work[color=darkred]
> > > in a way that sees a difference UNLESS you need to:
> > >
> > > (a) deal with global variables which would not be freed up until you[/color][/color]
> reset[color=green][color=darkred]
> > > code or exit the app, or
> > >
> > > (b) want to free up the memory prior to the end of the proc when the
> > > implicit freeing up would happen.
> > >
> > >
> > > --
> > > MichKa [MS]
> > > NLS Collation/Locale/Keyboard Development
> > > Globalization Infrastructure and Font Technologies
> > >
> > > This posting is provided "AS IS" with
> > > no warranties, and confers no rights.
> > >
> > >
> > > "Larry Linson" <bouncer@localh ost.not> wrote in message
> > > news:M66Db.1046 6$xO.6586@nwrdd c02.gnilink.net ...
> > > > "Tom van Stiphout" wrote
> > > >
> > > > > I just did. Results: no noticeable
> > > > > effects. Indeed VBA must be freeing
> > > > > memory behind the scenes. You
> > > > > were right all along.
> > > >
> > > > You don't suppose this might be one of those "it always does this[/color]
> > (except[color=darkred]
> > > > when it doesn't)" cases?
> > > >
> > > > We've seen enough of those cases in various software, including[/color][/color]
> Access,[color=green][color=darkred]
> > > over
> > > > the years, that I consider it "not just superstition" to set objects[/color][/color]
> to[color=green][color=darkred]
> > > > Nothing when I am finished with them.
> > > >
> > > > Larry Linson
> > > > Microsoft Access MVP
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Terry Kreft]

Re: Cleanup with Erase after Split?


An array variable is actually a pointer to a pointer to a struct, one of the
members of that struct is the pointer to the array data.

Quick sample
------------------

' *************** *************** ****
' Code Start
Option Explicit

Private Type SafeArray
cDims As Integer
fFeatures As Integer
cbElements As Long
cLocks As Long
pvData As Long
End Type

Private Declare Function VarPtrArray _
Lib "msvbvm60.d ll" Alias "VarPtr" ( _
Ptr() As Any _
) As Long
Private Declare Sub CopyMemory _
Lib "kernel32" Alias "RtlMoveMem ory" ( _
Destination As Any, _
Source As Any, _
ByVal Length As Long _
)
' *************** *************** *********
'

Private Sub Command1_Click( )
Dim a() As Long
Dim aP As Long
Dim aPP As Long
Dim SA As SafeArray

ReDim a(1 To 3)

aPP = VarPtrArray(a() )
Call CopyMemory(aP, ByVal aPP, 4)
Call CopyMemory(SA, ByVal aP, LenB(SA))
With SA
Debug.Print .cbElements
Debug.Print .cDims
Debug.Print .cLocks
Debug.Print .pvData
Debug.Print "---------------"
End With

Erase a

aPP = VarPtrArray(a() )
Call CopyMemory(aP, ByVal aPP, 4)
' a GPF occurs on the following line
' as aP is now zero i.e. it doesn't point to a
' valid array header
Call CopyMemory(SA, ByVal aP, LenB(SA))
With SA
Debug.Print .cbElements
Debug.Print .cDims
Debug.Print .cLocks
Debug.Print .pvData
Debug.Print "---------------"
End With
End Sub
' Code Start
' *************** *************** ****

There is a lot of information on this in Advanced Visual Basic 6 (Power
Techniques for Everyday Programs) by Matthew Curland.

Terry


"Tom van Stiphout" <tom7744@no.spa m.cox.net> wrote in message
news:jnlntv82ul gkr906qk98u0m0t 9tsd52s36@4ax.c om...[color=blue]
> On Sat, 13 Dec 2003 11:59:52 +1200, "TC" <a@b.c.d> wrote:
>
> It's my background in C:
> char * p;
> p = malloc(5000);
> In this case, p is a pointer variable. All such variables occupy 4
> bytes (using 4 bytes, you can adress 4GB of memory, which is all you
> need in a 32-bit operating system).
> In the second line, we make p point to 5000 bytes of memory that we
> allocate on the heap using the malloc function.
> When p goes out of scope, its 4 bytes are reclaimed, but the 5000
> bytes are not. The developer should explicitly call the free()
> function to get rid of the 5000 bytes.
>
> I see great parallels between this C program and VBA's ReDim and
> Erase.
> Since there *is* an Erase function, apparently VBA is not smart enough
> to know that memory was dynamically allocated and now needs to be
> reclaimed:
> Dim b() as Integer
> ReDim b(5000)
> ' use b
> Erase b
>
> FWIW, in .NET you no longer have to free() oe Erase: the garbage
> collector will do it for you.
>
> -Tom.
>
>[color=green]
> >But what leads you to say that the variable can go out of scope >without<
> >the associated memory being deallocated?
> >
> >TC
> >
> >
> >"Tom van Stiphout" <tom7744@no.spa m.cox.net> wrote in message
> >news:l3hjtv0dm oaqvi49nvhr4g2e n4nhr9fkef@4ax. com...[color=darkred]
> >> On Fri, 12 Dec 2003 16:03:48 +1200, "TC" <a@b.c.d> wrote:
> >>
> >> hmmm, you may be right, but I think memory-wise there is a difference
> >> between "a" and the memory "a" allocates. The variable will go out of
> >> scope as the stack frame will be cleaned up, but if a is a dynamic
> >> array, its dynamically allocated memory will not. My arrays will be
> >> small, perhaps 4 or 5 elements, but I will call this function many
> >> times.
> >>
> >> -Tom.
> >>
> >>
> >>
> >> >As you doubtless already know, 'a' will be deallocated as soon as it[/color][/color][/color]
goes[color=blue][color=green][color=darkred]
> >> >out of scope. So if it is a procedure level variable, it will be[/color]
> >deallocated[color=darkred]
> >> >on exit from the procedure. The only benefit to an explicit erase,[/color][/color][/color]
IMO,[color=blue][color=green]
> >is[color=darkred]
> >> >if the array is >way large<, and you have finished with it, but it[/color][/color][/color]
will[color=blue][color=green]
> >not[color=darkred]
> >> >go out of scope "for some time" (whatever that means). Then, the erase[/color]
> >could[color=darkred]
> >> >be used to reclaim the space immediately.
> >> >
> >> >HTH,
> >> >TC
> >> >
> >> >"Tom van Stiphout" <tom7744@no.spa m.cox.net> wrote in message
> >> >news:f8rftv0k3 qm7r2t1s9un7q7f 4o12166it5@4ax. com...
> >> >> I'm about to write a function like below, which I'm going to call a
> >> >> lot of times. So I care about possible memory leaks.
> >> >> I think whether I should use Erase or not depends on whether Split
> >> >> creates a dynamic array (similar to ReDim a(2)). I have a gut[/color][/color][/color]
feeling[color=blue][color=green][color=darkred]
> >> >> it does. Opinions?
> >> >>
> >> >> Dim a() as String
> >> >> a = Split("part1|pa rt2|part3", "|")
> >> >> ' code that uses a goes here
> >> >> Erase a
> >> >>
> >> >> -Tom.
> >> >>
> >> >
> >>[/color]
> >[/color]
>[/color]