So if you're passing an object as a parameter you're passing a copy of the pointer, even if you don't use the added var keyword in the parameter list. If you're passing something like a string or integer, the var keyword --> passing a copy of a pointer, so there's ultimately two pointers pointing to the same memory address. Not including the var keyword when passing a string or integer --> a copy of the string or integer data and a new pointer pointing to the copied data's memory address.
It's starting to make sense. Thank you! >From: Cosmin Prund <[EMAIL PROTECTED]> >Reply-To: Borland's Delphi Discussion List <[email protected]> >To: Borland's Delphi Discussion List <[email protected]> >Subject: Re: Learning OOP (part 3) -- follow-up >Date: Mon, 29 May 2006 12:24:13 +0300 > >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 -> [email protected] > > http://www.elists.org/mailman/listinfo/delphi > > > > > >_______________________________________________ >Delphi mailing list -> [email protected] >http://www.elists.org/mailman/listinfo/delphi _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
