• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 253
  • Last Modified:

Is it ok to have a class with no parent?

I am trying to track down some memory leaks in my project using Memory Sleuth. I am wondering if there is a problem declaring (formless) classes having no parent, thereby not calling an inherited Create and Destroy in the constructor and destructor respectively?
1 Solution
First of all, when you make an object that doesn't inherit from anyone, Delphi automatically makes Tobject it's ancestor. So you can ALWAYS call inherited destroy (Actually calling Free is recommended, because it checks for nil pointers before destroying).  So that will solve your problem. But I don't think the memory leaks comes from that!
boardtcAuthor Commented:

Thanks for the answer.

" So you can  ALWAYS call inherited destroy (Actually calling Free is recommended, because it checks for nil pointers before destroying)."

I always call Free, however what you are saying doesn't make much sense, I was asking about "inherited Destroy" the  last line normally in a destructor, you wouldn't use Free in this case. You say I can always call it, I am trying to find out is it cool not to in this instance (similiarly with inheritd create)..

Any other feedback anyone?

Thanks, Tom.
You can do that for decendent of TComponent only but not TClass in general. This is because all component has an owner, and the owner is reponsible to free the owned component before the owner itself is destroyed.
p/s: I hope I understand your question correctly: when you say parent you mean owner?

Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

You only have to explicitly call the destructor (or free or whatever) of the base class if it allocated memory. TObject does not do this., it only implements methods and you thus cannot leak by not calling it's destructor.

Where do you expect your leak is ? What do you do in your class ?
It is generally bad programming practice to use something like new or malloc in constructors because it can cause problems. If you do not do this the classes should destroy ok unless you are dropping pointers or not calling inherited destructors.

A common error is not declaring a virtual destructor in your class or actually the class of which type you are freeing. If you e.g. derive TMyObject from TObject and then access TMyObject via a pointer of type TObject simply freeing the TObject will result in a leak since the compiler and the app will not know that it is actually a TMyObject that has to be freed ! If you do have virtual functions that cause VTable entries to be made the code will determine the type from the VTable and it should free correctly. It is however a good Idea to always free something cast to the same type as it was created.

I do not know what you did in your code so forgive if this is completely off track ...

Hope that helped !
Hi tomcorcoran,
I don't know what's inside your classes, but if use descendent of TComponent instead of TObject (implicit also if don't declare anything) the memory management is always correct.
Delphi Help -> "Calling Free for a component, will call Free for all components that it owns, that is, all components in its component list."
So it shouldn't be so difficult to change yoru classes declaration inheriting from TComponent.
You just need to add AOwner in your create method.
e.g. declaring two kind of classes like follow :

TMyContained = class(TComponent)
   name : string;
   list : TStringList;
   procedure DoSomethingInside;
   . . .
   constructor Create(AOwner : TComponent);
   destructor destroy; override;

TMyContainer = class(TComponent)
    MyContained : TMyContained;
   constructor Create(AOwner : TComponent);


// TMyContainer
constructor TMyContainer.Create(AOwner : TComponent);
    inherited create(AOwner);
    MyContained := TMyContained.create(self);

// TMyContained
constructor TMyContained.Create(AOwner : TComponent);
    inherited create(AOwner);
    list := TStringList.create;

destructor TMyContained.free;
    // if you have objects in the list you must make a loop to free any of them
   //  before freeing the list
    inherited destroy;

This way you'll discard any allocated memory. Note that because of TStringList doesn' descend from TComponent you need to free it by code.
So if you want to declare something directly descending from TObject you must manage by yourself free and destroy methods.
Sometimes, like using TStringList, it's necessary.
I hope tehere's something helpful for you .
boardtcAuthor Commented:
Giovanni, thanks for the reply, I have many classes liker this, this is not what I am asking however, JimBob pretty much answered it, saying it's cool not to call the inherited create and destroy when TObject is the parent (explictly or implicitly). JimBob, let's put this one down, most a dummy answer and I'll grade. Tom.
Hi Tom,
you wrote about 'Memory Sleuth', is it a good tool for memory management ?
I've been on FILEZ looking for it but I couldn't find anything.
I'm looking for a good tool so please tell me more about it.

boardtcAuthor Commented:
Hey, check out UNDU - http://www.undu.com/Articles/980807c.html, I find Memory Sleuth the best. Tom
Hi Tom

I had actually commented in your other question, so only found your comment here by coincidence!  :-)

Anyway, if you're happy with my comment on the other question and are still happy for it as an answer, then here it is.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now