Re: MD7 Q's

From: Maarten Wiltink (maarten_at_kittensandcats.net)
Date: 10/13/03 

Date: Mon, 13 Oct 2003 12:40:44 +0200

MW wrote in message ...
[...]
>Say you define a TButton and instatiate it as follows
>
>procedure TForm1.FormMouseDown [..]
>var
> Btn: TButton;
>begin
> Btn := TButton.Create (Self);
>end;
>
>Am I corrent in assuming that this instance of TButton, Btn, only
>gets freed once I close Form1? (unless if I call the free/destroy
>method myself)

Yes. Although in some scenarios, Form1 might be freed before the
application closes. It's not as bad as it may seem.

>Also, which properties of Btn are set by TButton.Create, if any, or
>do I need to populate all of its properties?

Owner. Nothing else. In particular, not Parent.

>Now say, I went and instantiated an object of type TStringList.
>
>procedure StoreNames;
>var
> Names : TStringList;
>begin
> Names := TStringList.Create;
> With Names Do
> Begin
> Clear; { is this necessary }

No. It's not a _bad_ habit, though.

> Add('Rob');
> Add('name');
> Add('MW');
> End;
> // ClearList(Names);
> Names.Free;
>end

>Does the above code (Names.Free) take care of cleaning up properly?

Almost. It's common, and a good habit for obvious reasons, to start
a try-finally statement immediately after object construction, and
_make sure_ that any object created is also freed.

>I've read some code where the programmer did cleaning up that freed
>each of the strings that were added individually. (commented out
>ClearList)

<snip code>

>Is [ClearList] really necessary?

That depends. We had a long thread last year(?) about many schemes for
destroying objects properly, and one of the outcomes was a recognition
of the difference between lifetime management, reference management,
and another one that I can't remember but wasn't as important (since it
often coincided with one of the other two).

Having a reference to some object does not make you responsible for
freeing it. But _someone_ should have that responsibility, and if it's
the stringlist, then it should call ClearList before destruction. But
this is not very common; usually lists merely keep aliases which don't
carry the burden of destruction. Note how the TObjectList is a later
addition, much like FreeAndNil.

The commonest case is to have the code that allocates an object be
responsible for freeing it. It's relatively rare to transfer the
obligation to any list that refers to it. But it's an option (though
not usually the best).

>Also, what happens to Names, if I do not call Free. Does Delphi not
>clean up for a local variable of type TStringList, like it would have
>for a variable of type String, when the procedure closes?

There are two important distinctions: that between data that live on
the stack vs. data that live on the heap, and reference-counted objects
vs. manually destroyed objects.

Data structures that live on the stack are reclaimed when they go out
of scope. Reference-counted objects are reclaimed when the reference
count drops to zero.

Strings consist of a variable that (in the simplest case) lives on the
stack, and possibly the actual string value (if not empty), which lives
in the heap but is reference-counted. Normal objects live on the heap,
too, but there may be many references to them from anywhere. But they're
_not_ reference-counted. This is the normal case; if anything, strings
should be considered special, not objects.

Groetjes,
Maarten Wiltink