What you've got in your "sl" variable is not the data associated with
"sl" but a pointer to that data. When you pass "sl" as a parameter to
your test function you're passing a copy of the pointer, so the called
procedure would be working on the same area of memory. That's why you
get all three messages.
This is very important and you need to understand this: Objects are
Pointers! When you're passing an object around you're only passing it's
pointer, the 4 byte value that tells you where the object's actual data
is. If you think about it in depth, it really makes sense. There's no
way to reliably copy an object's data to obtain a perfect replica of the
given object because objects may contain things like handles to system
resources or pointers to other objects. Even if you were able to
perfectly copy an object, copying it around every time you called a
procedure tacking an object as a parameter would be highly inefficient.
Using an "pointer to an object" would again be a nonsense since objects
are already pointers and that would simply introduce an unwelcome extra
layer of indirection that would make our lives way more difficult and
would make code less efficient.
P.S:
Other languages (ex: C++) also have non-pointer objects because they can
"host" objects on the stack or in the data section of memory
(non-dynamic memory). In those languages there's no equal sign between
objects and pointers and in C++ your code MIGHT have worked as expected.
If the TStringList had something called an "copy constructor" and sl
would have been an stack-based object, it's data would have been copied
as part of the call to the test procedure (using the copy-constructor)
and then the used memory would have been destroyed upon return of the
"test" procedure (calling the destructor). Also my limited experience
with C++ tells me you don't use stack-based objects that often and you
end up doing manual dereferencing of pointers all over the place. So I
think Delphi's way is much better!
Alan Colburn wrote:
> Thanks to all three of you for your responses--very helpful. As I think
> about it, it seems almost intuitive (after a couple days :-) that objects
> should be freed by the same class instance in which they were created, if
> possible. I appreciated your responses about passing parameters, too, and
> started experimenting a little, just to cement my understanding.
>
> I created a class called TSample with a single procedure, test
> (sl:TStringList). It's got two lines: sl.Add('TSample'); and
> ShowMessage(sl.Text). I experimented with calling the procedure, passing the
> stringList in various ways. I understood, I'm happy to say ... except for
> this:
>
> Form1's got this code:
> sl:=TStringList.Create;
> sl.Add('TForm1');
> x:=TSample.Create;
> x.test(sl);
> sl.Add('TForm1 again');
> ShowMessage(sl.Text);
> sl.Free;
>
> The last ShowMessage has all *three* lines ('TForm1','TSample', and 'TForm1
> again'). It seems to me that if it's a *copy* of sl that's passed to the
> called procedure, then that last ShowMessage should just have *two* lines
> ('TForm1' and 'TForm1 again'). In other words, it seems like the procedure
> is acting the way I would now predict it would (and does) if I change the
> signature to TSample.test (var sl:TStringList).
>
> What do you think?
>
> Thanks, as always -- Al
>
> p.s. I'll stop asking so many questions soon ... don't want to overstay my
> welcome :-)
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today - it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
> _______________________________________________
> Delphi mailing list -> Delphi@elists.org
> http://www.elists.org/mailman/listinfo/delphi
>
>
_______________________________________________
Delphi mailing list -> Delphi@elists.org
http://www.elists.org/mailman/listinfo/delphi
