I think perhaps the apparent complexity introduced because objects are always passed as pointers is confusing the underlying meaning of the "var" keyword. Better if you are clear about the simple case first, so... For the integer example you quoted: Procedure A(x: integer); // A copy of the VALUE of X is passed, x can be the result of evaluating an expression Examples A(1); A(b); A(c*d);
Procedure D(var x : integer); // the ADDRESS of x is passed, x must be a variable, any assigment to x affects that variable Examples D(E); D(F); // no expressions or constants! HTH, Ken -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Colburn Sent: 30 May 2006 06:01 To: [email protected] Subject: Re: Learning OOP (part 3) -- follow-up 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 _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
