It was usually flagrant disregard in using the correct descriptive
name. I continually call everything objects even though I know I shouldn't.
What I meant was say in the case of an long string where Delphi usually
allocates and deallocates memory as required and uses reference counting to
know if and when it should be free'd, I do understand why you show the
behavior as changing in this case...why Move interferes with this...but I
don't like the idea that it's basic behavior can even be changed this way
simply because of the circumstances under which it is being used. That just
doesn't seem like good design to me. Worse yet, I had never seen this
mentioned anywhere before!
from Robert Meek dba Tangentals Design CCopyright 2006
"When I examine myself and my methods of thought, I come to the conclusion
that the gift of Fantasy has meant more to me then my talent for absorbing
positive knowledge!"
Albert Einstein
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Rob Kennedy
Sent: Tuesday, March 14, 2006 4:37 AM
To: Borland's Delphi Discussion List
Subject: Re: Objects and Lists...addendum -> Strings
Robert Meek wrote:
> What I'm glad I finally did get out of my questioning was Rob's
> information on how use within an array inhibits the normal reference
> counting Delphi uses
You misinterpreted my article. It's _not_ the array that circumvents
reference counting. It's the use of Move to quickly shift everything
around in the array. I think the article is pretty clear about that. I
was about to provide an example here to demonstrate how to modify a
dynamic array without using Move, Initialize, and Finalize, to show that
it's perfectly safe, but what I came up with turned out to be exactly
what I gave in listing 1.
As I look at the article now, I see that I really should re-organize it;
I shouldn't mention Move so early, lest it appear that it's the
preferred technique.
> as I never would have considered that and would have
> ended up with some pretty nasty memory leaks that would be difficult to
> account for! <g>
And not just memory leaks. Access violations or invalid-pointer
operations, too.
> I personally consider this difficulty a very un-natural
> condition that should have been accounted for properly by the compiler.
It was. But Move circumvents any type-checking the compiler could do. As
type-safe as Delphi is, and untyped var and const parameters are one
glaring hole in it, as the names would imply.
> Looking into this mystery I learned things about the way Delphi manages
> strings and other reference counted objects that I didn't know about.
There
> are probably many very good reasons for why they did these things as they
> did, but just from my shortsighted view of it all I think I would have
> handled these things a little closer to the bone...meaning that I would
have
> made the allocation and freeing of memory needed for their dynamic sizing
a
> part of the objects themselves.
They're not objects.
And the allocation is handled as part of the language itself. You can't
get any closer to the bone than that when you're designing a programming
language.
> I've never been comfortable with the
> concept of an object's use affecting its natural behaviour.
I don't think I know what that means.
--
Rob
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
