Hi,

Can any problems with stringsclass.pas ?
Reason I ask is that, yes my fairly large program works that uses dynamic memory allocation, however it has memory leaks galore! :( stringsclass.pas is a dynamic string class I created which I take pride in, but I'm not convinced I wrote the: procedure del(index: Integer); correctly...
Could someone have a look and comment on that please ? It will aid greatly in my efforts to debug my memory leaks...

cheers
James

With all due respect, but this is not exactly the most efficient code ever. Did you have a look at the standard TStringList class ? It works very well, and does all you do.

Also, Class destructors MUST be called 'Destroy', not 'done'.

Your method of calling init/done is also not quite correct, you're not supposed to call the destructor unless you actually want to free your class.

If you want to stick to your class, try replacing your code with this=

procedure TStrings.del(index: Integer);
var
 I : Integer;
begin
 For I:=index to nstrings-1 do
   Strings[i]:=Strings[i+1];
 Dec(nstrings);
 ReallocMem(strings,sizeof(Shortstring)*nstrings);
end;

Using this I get no memory leaks.

Michael.

Yeah I found out there was TStringList after I wrote it. And I'll agree with you, it's not the best code. However other classes that dynamically allocate objects in memory use similar code to that of stringsclass.pas so I need to get this right :)

Also, Class destructors MUST be called 'Destroy', not 'done'.

Okay.

Would this same technique work for a general dynamic array of objects ?

Using this I get no memory leaks.

I get none with my version either (don't know why) ...

James

I'll show you... Catch, datanicks.pas and nickclass.pas ... This is why I need to understand and fix this, it's not just a simple TStringList that I want to use :)

thanks for your help ...

cheers
James

It should, unless you use memory pointers that point to specific memory locations in the array.

Michael.

Forgot to attach em :(

cheers
James

Okay, thanks.

btw ... Is this how you write classess properly ? (destroy destructor as you said ...)

type
   TTokenizer = class(TObject)
      constructor init(tmpStr: String);
      constructor init(tmpStr: String; tmpDelim: Char);
      destructor destroy; override;

.
.
.

destructor TTokenizer.destroy;
begin
   inherited destroy;
end;

It should work with this class too.

Michael.

James,

didn't I send you a revised version of this ages ago... even if you dumped the whole of it I would have pointed out why not to use Init and Done over Create and Destroy. I'll tell you one good reason why you may have memory leaks... 'done' will never get called if you 'free' an instance of TStrings. That alone will cause a memory leak.

You did see TList too, right? TStringList and TList will do everything you want, and TObjectList is another good one (if fpc has it implemented.) For 1.1 also look out for TInterfaceList (one of my favourites in Delphi) and there's also the heavy handed but usefull TThreadList in multithreaded environments ;-)

In fact, looking at your code, your biggest problem is that you missed how the destructor works in Object Pascal. TObject has a virtual destructor called 'Destroy' that gets called when you call 'Free'. Calling the destructor directly is simply wrong. If you are using Turbo Pascal mode, you should be calling 'dispose( instance, destructor );' and in Object Pascal (Delphi like) mode it has to be 'instance.free' which will indirectly call the destructor. If you name your destructor something random and call it directly, it will leak memory like a sieve.

Also it would be worthwhile take a look how inheritence works. Look, for example, at the definition of TObject. The destructor is defined as 'destructor Destroy; virtual;'. The 'virtual' is the clue here. You must 'override' this method to get things to work propperly!! Your destructor needs to call 'inherited destructor' to have any chance at not leaking memory.

destructor TStrings.Destroy;
begin
  //whatever deallocation
  inherited; //also valid : 'inherited Destroy;'
  //like 'super' in java
end;

Naming your constructor as Init, whilst not technically incorrect, breaks naming conventions and will cause you endless problems if you should ever wish to derrive your class from somewhere else other than TObject. So, once interfaces come into play in 1.1, you would want to descend from TInterfacedObject, and not calling the inherited constructor could be a real problem. Another classic problem is TThread. Try creating a TThread descendent and overriding the constructor but not calling the inherited version. The thread never starts ;-) Got caught by that one a few times.

Matt

---------------------------------------------
This message was sent using Mistral WebMail.
http://www.mistral.co.uk/

Okay, I didn't know this. Thanks. Sorry if you've tried helping me before, too much uni work I guess and it was a long time ago...

Thanks Matt :)
Be a lot of re-writing...

cheers
James

It is implemented.

Michael.

This is OK. It's also customary to call the constructor 'Create'. It reflects more what is happening, namely that *new* memory is allocated. 'Init' reflects more that *existing* memory is initialized. (which is more an old TP construct)

Michael.

Okay. Thank you :)

James

Hi everyone -

is there any way to call a virtual method of a class from within an assembler block/function/method?

I checked out FPC's generated-assembler source but it uses a constant-offset, e.g.:

movl (%esi),%edi
call *92(%edi)

the "*92" is the offset for that particular method in the classes' VMT, but is there any way I can obtain this number myself? (is it a named constant anywhere?? I only need it at compile-time) Calling the method by name works for that class but doesn't recognise "override" methods in descendents....

Thanks in advance...

There is no way to retrieve this information, you need to calculate the offset yourself. Also note that the calling of methods will be little different between 1.1 and 1.0.x and it is therefor not recommended to call methods from assembler code. You can make a pascal wrapper arround the method

Peter