thanks for your attention to this.
{snip}
var
MyObject :pMyObject;
begin
new(MyObject);
MyObject^ := TMyObject.Create;
MyObject^.MethodCalls;
MyObject.Free; //
Notice that there's no ^
dispose(MyObject);
end;
This helpful autodereference makes much of Delphis
syntax easily readable but like all
things there's a downside too...
I didnt try this and its too late since I got rid of all the pointer
types, news, and dispose's. It simplified
up a whole lot, except that I had to explicitly set the StringGrid[col,row]
to nil after I did the free, since my test
of (MyStringGrid[col,row] is tMyObject) failed with an
invalid memory access.
I will try NuMega's bounds checker to see if it handles the memory dispose reporting better. I am not so sure that Delphi's pointer guessing makes it easier or harder, especially if one has been tainted with doing it all with pointers in the past.
regards
Leo
Aaron Scott-Boddendijk wrote:
Sorry I'm jumping after being off the ball for a bit but I would point the finger at MemorySleuth in this--------------------------------------------------------------------------- New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
instance.> pMyObject = ^tMyObject;
> tMyObject = class
> ...
> end;
>
> I created objects and saved them in a StringGrid;
>
> var myObject : pMyObject;
> begin
> new(myObject);
> MyObject^ := tMyObject.create;
> MyObject^.Methodcalls
> MyStringGrid.Objects[Col,Row] := MyObject;By requesting memory using New with the identifier 'myObject' then making the
assignment to an untyped pointer inside the StringGrid the memory tracker is likely
failing to follow the assignment of memory to a valid destination - most of the syntax
tracking methods require some fairly tight type binding to let them cross procedure
boundaries...> then I disposed of the object in the end;
> tMyObject(MyStringGrid.Objects[Col,Row]).free;
> dispose(MyStringGrid.Objects[Col,Row])It's likely that MemorySleuth hasn't associated the Dispose of the Stringgrid
pointer with the New used to allocate the memory... The Dispose would produce an
error if Disposing memory illegally so it's safe to say the memory there has been correctly
handled.> TurboSleuth reported an undisposed memory from the new line.
> When I recoded to use a tMyObject instead of a pMyObject (and dropped the
> associated new and dispose calls) the leak disappeared. I am more clever now,
> though no wiser. Any insights or explanations?Part of your confusion will be Delphis assistance in dereferencing pointers for you...
> var myObject : pMyObject;
This creates [myObject] -> nil
> new(myObject);
this creates [myobject] -> [a TMyObject handle] -> nil
> MyObject^ := tMyObject.create;
this creates [myobject] -> [a TMyObject handle] -> [An actual object]
> MyStringGrid.Objects[Col,Row] := MyObject;
Syntactically this should be doing [MyStringGrid.Objects[Col,Row] -> [a TMyObject Handle]
but then shouldn't
> tMyObject(MyStringGrid.Objects[Col,Row]).free;
produce an error since you've not dereferenced the pointer for access to Free. Delphi is doing
this for you.if you translate the above to remove the StringGrid
var
MyObject :pMyObject;
begin
new(MyObject);
MyObject^ := TMyObject.Create;
MyObject^.MethodCalls;
MyObject.Free; // Notice that there's no ^
dispose(MyObject);
end;This helpful autodereference makes much of Delphis syntax easily readable but like all
things there's a downside too...--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
